TL;DR
OpenDuet is CopilotKit’s early MIT-licensed template for a self-hosted proactive agent. Its practical design question is not whether a bot can run in the background, but where observation, preparation and externally consequential actions are separated by an approval boundary.
Introduction
An agent that waits for a prompt is easy to interrupt: it usually stops when the user stops asking. A proactive assistant must decide when to check for work, what to prepare, when to interrupt its owner and which actions require permission. Each decision trades convenience against noise and risk.
CopilotKit announced OpenDuet on October 27 as a self-hosted template for that pattern. It describes a morning brief, background checks, a persistent conversation and a separate computer with a browser. Before sensitive actions such as sending messages or deleting items, the company says the assistant asks the user. These are project claims, not results of an independent deployment test. (Source : CopilotKit — Introducing OpenDuet)
Proactivity is a workflow, not a permission
A useful way to evaluate the architecture is to split a task into stages. First, an agent observes authorized information, such as a calendar. Second, it interprets and prioritizes. Third, it prepares a proposed action. Finally, it may act on an external system. Those stages have different failure modes and need different controls.
For example, a morning brief can be wrong without immediately sending a message to the wrong recipient. A draft reply can be edited before delivery. The transition from draft to send is therefore a natural place for human approval, provided the approval is bound to the exact recipient and content that will actually be sent.
OpenDuet’s announcement describes allowing an action once, always allowing it or refusing it. That flexibility is useful, but persistent permission creates a new responsibility: scope, expiry, revocation and auditability should be clear. An approval for one invoice should not silently become permission to pay any invoice. (Source : CopilotKit — OpenDuet announcement)
Self-hosted is not the same as dependency-free
The project runs on OpenBot, with OpenDuet-specific bots, skills and settings. Its repository describes the project as early and actively changing. It also says CopilotKit Intelligence is required for conversation threads and memory and that a key is needed to start the server. The announcement describes a free Intelligence key; model and third-party service costs are separate questions. (Source : OpenDuet — Repository)
That distinction matters for privacy planning. Hosting an application on your own infrastructure gives control over some components, but it does not prove all data remains there. Operators must inspect what the required service receives, where model calls go, which connectors hold credentials and what logging or telemetry is enabled. A deployment diagram is more informative than the phrase self-hosted alone.
The repository is distributed under the MIT license. That permission applies to the repository, not automatically to every model, service or connector integrated with it. (Source : OpenDuet — MIT license)
Designing an approval that survives contact with reality
A robust approval should identify who requested it, the tool and account involved, the exact proposed operation and the scope of any future permission. For a message, show recipients and content; for a deletion, show the target; for a payment, show amount and destination. If material details change after approval, the authorization should be reconsidered.
That is a design recommendation, not a claim that OpenDuet implements all these controls. The project describes an approval boundary and an audit trail, but the published description alone is not a security audit. Builders should test direct tool calls, alternative connector paths, retries and agent restarts to see whether the same policy applies consistently. (Source : OpenDuet — Repository)
The agent’s own computer is another boundary. A browser can improve resilience when a laptop is closed, but it also expands the attack surface: untrusted web content can attempt to influence what the agent does. Restricting credentials, isolating the runtime and using least-privilege accounts remain necessary even when a confirmation dialog exists.
How to measure usefulness without rewarding noise
A proactive assistant should be judged on outcomes rather than the number of notifications it generates. Track actionable alerts, false interruptions, time saved after review and errors found before execution. For approvals, track both missed risky actions and routine actions that repeatedly require human intervention.
Start with read-only access and draft-only workflows. Compare the brief with what the user actually needed to see, then expand the scope only where the benefit is clear. Keep a rollback path and review the permissions that have become persistent. A system that asks for approval so often that users stop reading is not safer merely because it displays a dialog.
OpenDuet is an interesting reference implementation precisely because it makes these product trade-offs visible. Its long-term value will depend less on claiming autonomy than on whether users can understand, constrain and reverse the autonomy they grant.
FAQ
Is OpenDuet fully local?
Not by default as documented: the project requires a CopilotKit Intelligence key for threads and memory. Check the current documentation and data flows before deployment.
Does self-hosting remove model costs?
No. Model providers and other services can charge separately.
Are approvals a substitute for security testing?
No. The boundary and all paths to sensitive tools still need testing, alongside credential and runtime isolation.
Is the repository open source?
Yes. Its repository uses the MIT license, while dependencies may have different terms.
Further Reading
— The Agent Report