# Persistent agents in production.
Canonical source: [https://isaiuseful.com/persistent-agents](https://isaiuseful.com/persistent-agents)
Enterprise operations · checked 1 October 2026
Keep the work alive across sessions. Give the organization control over who can act, which tenant they serve, when humans intervene and whether the workflow pays back.
- [Read the editorial](#natural-habitat)
- [Design the approval flow](#approvals)
- [Set the 90-180 day test](#roi)
Landscape · checked 1 October 2026
## See how vendors present persistent agents.
Four vendor promos make the landscape tangible: agents with memory, tools and work that continues between conversations. These are marketing demonstrations, not independent evidence of reliability, security or ROI.
- [Video: Introducing dots, always-on agents built to handle everything.](https://www.youtube.com/watch?v=uXspbC2srEQ)
Vendor promo · OpenAI
### Dots: ongoing work in ChatGPT
OpenAI presents an always-on agent with its own cloud computer, connected apps and remembered context. Give it an ongoing goal and review the work and decisions it brings back.
- [Dots capabilities and availability →](https://help.openai.com/en/articles/20001530-getting-started-with-your-dot)
- [Video: Introducing Muse: your personal AI agent](https://www.youtube.com/watch?v=We8BTITLvb4)
Vendor promo · Meta
### Muse: a personal agent with its own computer
Meta presents a persistent cloud computer and browser for tasks across connected services. The pitch includes background progress, remembered goals and approval requests for sensitive actions.
- [Muse announcement and rollout →](https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/)
- [Video: Introducing Grok Bot](https://www.youtube.com/watch?v=F1_0Lkp16Rc)
Vendor promo · Grok
### Grok Bot: a team of always-on workers
Grok presents bots with their own computers that work across apps and inboxes, remember conversations and return for approvals. Its examples span sales, operations and engineering.
- [Grok Bot announcement and beta access →](https://x.ai/news/introducing-grok-bot)
- [Video: The new Copilot: where AI-powered work comes together](https://www.youtube.com/watch?v=OgInADh5Tcs)
Vendor promo · Microsoft
### Copilot: Home, Code and Autopilot
Microsoft's broader Copilot promo includes Autopilot, a persistent agent with its own identity, memory and workspace in the organization's tenant. Autopilot is expanding through a private preview.
- [Copilot announcement and preview status →](https://blogs.microsoft.com/blog/2026/09/25/introducing-the-new-copilot-with-home-code-and-autopilot/)
**EU availability · checked 1 October 2026:** Muse is not available in the EU; [Meta describes a US rollout](https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/) . OpenAI dots are not available to EU Pro users: the rollout excludes the EEA, Switzerland and the UK. [Business Premium access covers supported ChatGPT regions](https://help.openai.com/en/articles/20001530-getting-started-with-your-dot) , including the EU, and EU Enterprise customers can use the beta when their [workspace admin enables dots](https://help.openai.com/en/articles/20001554-manage-dots-in-chatgpt-workspaces) . Access is rolling out gradually.
**FOSS counterparts:** [OpenClaw](https://isaiuseful.com/tools.html.md#tool-openclaw-companion-apps) and [Hermes](https://isaiuseful.com/tools.html.md#tool-hermes-agent) are free and open-source routes to the same broad idea: persistent assistants that retain context and use tools to carry work forward. Their place in this landscape does not depend on a vendor promo. Self-hosting leaves deployment, model access, integrations and operating controls for you to choose and verify.
**Hermes enterprise backing · 7 October 2026:** Nous Research confirmed a Series B and a planned mobile app in its [announcement](https://x.com/NousResearch/status/2107874963382538469) . CEO Dillon Rolnick's [fundraising note](https://nousresearch.com/a-note-on-our-fundraise) confirms $90M raised, with NVIDIA, Microsoft's M12, Samsung, Robot Ventures, Union Square Ventures, Y Combinator and Menlo Ventures among the investors, to build Hermes for Businesses. The [Wall Street Journal reports a $1.5B valuation and more than 22M downloads since February](https://www.wsj.com/pro/venture-capital/nous-research-scores-90-million-to-bring-open-source-ai-assistant-to-enterprises-516f9208) ; Nous separately reports more than 24M clones. This backing makes Hermes a stronger candidate for an enterprise evaluation. Downloads and clones are not unique active users, and funding does not establish tenant isolation, reliability or measured ROI.
**Look underneath the interface:** Meta documents editable [`Soul.md` , `Identity.md` and `Memory.md` files in Muse](https://www.meta.com/help/artificial-intelligence/2225571704857152/) . [OpenClaw's workspace files](https://docs.openclaw.ai/concepts/agent-workspace) and [Hermes's `SOUL.md`](https://hermes-agent.nousresearch.com/docs/user-guide/features/personality) use a similar pattern of editable identity and context. Shared file conventions help explain the design; they do not establish identical implementations or safeguards.
Editorial · 1 October 2026
## Give an agent somewhere to work.
A productive persistent agent needs tools, working systems, tests and a way to learn from failure. That habitat can support software maintenance, an inbox or an operational workflow.
An agent's natural habitat is an environment it can actually use: a repository, a mailbox, internal records, a browser or application, test data and a clear definition of done. Persistence gives it time to complete the loop. The organization supplies the scope, safeguards and visible delegation that make the result worth accepting.
Read the full editorial
Coding, OpenSpec, Hermes workflows and a FOSS build path
### Start with a coding bot's working day
Imagine a bot assigned to maintain an internal application. A permitted error feed reports that a form sometimes loses a saved value. The bot claims the issue, starts a clean workspace at a recorded commit, loads synthetic test accounts and reproduces the failure in the application. It keeps the failing steps and logs alongside the task.
Then it reads the relevant code, writes a regression test that fails for the original defect, makes the change and runs the relevant checks. It opens the application again, follows the same journey and checks nearby behavior: keyboard navigation, a narrow screen, an expired session or a failed request, as applicable. A screenshot or recording makes the visible result inspectable; assertions establish what the test actually proved.
The output is a reviewable change with the reproduction, diff, test results, remaining uncertainty and rollback path. If a release needs approval, the bot prepares that decision and can move to other authorized work while it waits. After an approved release, it checks the agreed health signals and reports whether the original symptom returned. That is a complete maintenance loop.
Vendor example: [Cursor's cloud-environment account](https://cursor.com/blog/cloud-agent-environment) describes simplifying build commands and giving agents computer use and recordings to validate running software. It supports the environment pattern; the working day above is our proposed design.
### Specify the work beyond software
The same operating pattern can take over work previously assigned to a person: tracking deliveries, maintaining support records, reconciling routine documents or preparing recurring reports. A coordinator's day often connects messages, decisions and updates across several systems. An agent can perform that chain when the inputs, permitted actions, exceptions and completion evidence are explicit. How much of a human role it can replace is a question for measured outcomes, including the supervision and recovery it still needs.
[OpenSpec](https://openspec.dev/) gives us a useful starting method. Its documented purpose is managing software specifications, with proposal, requirements, design and task artifacts that guide implementation and verification. Our proposed extension is to apply that discipline to business workflows: describe the trigger, trusted input sources, records it may read or change, people it may contact, deadlines, acceptance criteria and escalation path. The [specification loop](https://isaiuseful.com/thinking-with-ai.html.md#loop) already offers a way to make these decisions reviewable.
For vendor coordination, the specification might permit updating a delivery estimate for an existing purchase order and sending a routine acknowledgment. It can reserve changed prices, payment details, contract terms and disputed deliveries for a human. Version that contract with the workflow and its tests. OpenSpec can organize the requirements; the deployed application's authorization checks must enforce them.
### Let Hermes close an operational loop
[Hermes documents an email gateway](https://hermes-agent.nousresearch.com/docs/user-guide/messaging/email) that receives messages and replies through IMAP and SMTP. It also distinguishes that gateway from its Himalaya email skill for inspecting and managing mailbox messages. Its [MCP support](https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp) provides a route to additional tools. These components are a starting point for a workflow with internal systems; the integration and business rules still have to be built and tested.
Imagine a dedicated vendor mailbox. A supplier reports that an existing order will arrive two days later. The workflow checks the sender and order against trusted records, extracts the proposed date and prepares an update. A narrowly scoped service checks the allowed fields and current record version, applies the authorized change and returns a receipt. Only then does the agent send the permitted acknowledgment to the approved recipients. If the update fails or the order cannot be matched, it escalates instead of claiming success.
Keep a durable link between the incoming message, internal update and outgoing reply. Use a stable operation key to prevent a duplicate message or restart from repeating the write; track reply delivery separately so a failed send can recover without reapplying the update. Reconcile uncertain delivery status before resending. External correspondence remains task data. A vendor's message must not become permission to run commands, change the workflow or access another customer's records. The gateway's sender controls are useful, but a vendor who may supply an update should not inherit an operator's tool authority.
### Build the sandbox before connecting real work
Begin with synthetic mail, a test mailbox, disposable records and an isolated worker. Limit filesystem access, host mounts, credentials and outbound destinations to the task. Keep each tenant's memory, files and connections separate. Start with drafts and proposed changes; enable a bounded write or reply only after its acceptance and failure cases pass.
Mailbox reads, internal writes and external sends need separate grants. Keep credentials in a broker or narrowly scoped connector, and validate the target, permitted fields, recipients, attachments and spend at execution. A container can constrain local commands while a connected mail service still sends a harmful message with valid credentials. The tool boundary has to govern that action too. The [Hermes security guide](https://hermes-agent.nousresearch.com/docs/user-guide/security) documents container backends, command approvals and other configurable defenses; their presence still requires an appropriate deployment and review.
Test hostile instructions in emails and attachments, forged senders, duplicate messages, stale records, changed recipients, partial writes and unavailable services. Require the agent to preserve its original authority throughout. Store the evidence needed to reconstruct the action, restrict access and avoid retaining entire private conversations by default. Use the [decision ledger](#audit) and [personal-data guide](https://isaiuseful.com/eu-gdpr.html.md) when defining the deployment's records and retention.
### Make the delegation visible
The organization should know which workflow an agent operates, whose authority it uses and who can stop it. People receiving its correspondence should know they are dealing with an automated assistant and how to reach the accountable human. Give the agent an honest identity and signature, and explicit limits on promises, meetings and commitments. Put the deployment through the organization's normal ownership and budget process.
There is a funny, awkward illustration in [this Reddit account of a Hermes vendor coordinator](https://www.reddit.com/r/hermesagent/comments/1voge9w/a_vendor_asked_my_hermes_agent_out_for_coffee_and/) . The author says they quietly substituted an agent for a planned hire, gave it a fictional human identity on company email and let it coordinate with suppliers. A vendor then invited the supposed colleague for coffee, and the agent agreed to find a time. This is an unverified personal account, rather than evidence of productivity or typical Hermes behavior.
The invitation makes the missing boundary easy to see. A correspondence workflow can create expectations and commitments even when it changes no code or money. An honest assistant identity, a named owner and a rule that routes personal invitations or new commitments to a human would make that moment manageable. Useful automation earns trust through visible, authorized work and recoverable mistakes.
### Put billion-token weeks in the capacity plan
For a bot doing sustained coding, research, coordination, tool use and verification, substantial token throughput should be an ordinary operating consideration. Every iteration brings context back into the model: code, documents, correspondence, instructions, tool results and earlier decisions. Running several bounded tasks over a week can produce a very large usage total.
**One billion tokens per week is an editorial planning scenario here.** For example, 10,000 model calls averaging 100,000 combined input and output tokens total one billion tokens. That arithmetic includes repeatedly supplied context and any cached input counted by the provider. It does not describe a billion tokens of newly written code or establish a measured industry norm.
Budget fresh input, cache reads, cache writes, reasoning and output according to the provider's actual accounting, alongside tool and machine costs. Then divide total operating cost by accepted tasks. A bot that fixes valuable defects or completes useful business transactions may justify substantial usage; a bot that keeps rereading its context without producing accepted work needs a different loop. Give each task a spend ceiling, bounded retries and a stop when repeated attempts produce no new evidence.
### Build for the agent's feedback loop
An agent workspace does not have to reproduce a human's desk or working day. Make the environment easy to discover and cheap to reset. Provide documented routes to start the application or workflow, run its checks and restore realistic fixtures, with clear output when a service fails. Supervise long-running processes outside the model so the bot can concentrate on the task.
Prefer a stable command or API for precise operations, and provide browser or native application access wherever behavior must be experienced. A passing unit test cannot show that a dialog covers the save button. A screenshot cannot prove that a permission boundary holds. The agent needs the evidence appropriate to each claim, including failure cases the implementation did not anticipate.
Keep the task queue, acceptance criteria, checkpoints and decisions in durable storage. Record which code, workflow version and environment produced each result. Resume by inspecting current state, including completed writes and expired approvals, so a restart cannot quietly repeat a consequential action.
### Start with one worker and a small control stack
Our first implementation would have a tenant-scoped task store and scheduler, an isolated worker running the chosen harness, a tool broker enforcing named targets and short-lived credentials, an approval service and an evidence store. Give tasks explicit states such as queued, running, waiting for approval, verified, failed and completed. Atomically claim work with an expiring lease, and check permissions at the point of execution.
Begin with one worker and one recurring job, such as preparing fixes for a bounded class of bugs or handling routine delivery updates for one team. Add concurrency when the queue warrants it. A separate reviewer can challenge the acceptance evidence, while execution gates remain application policies owned by accountable humans. The [one-hour decision policy](#approvals) and [decision ledger](#audit) below describe those boundaries.
### Use Grok Bot and Cursor as experiments
Grok Bot through an eligible SuperGrok or Cursor plan is a useful place to experience this workflow. SpaceXAI's [launch account](https://x.ai/news/introducing-grok-bot) describes internal engineering bots reproducing UI bugs and handing fixes to other bots. Its [engineering marketplace](https://x.ai/bot/marketplace/engineering) offers templates to import, including a [SWE bot by Cursor](https://x.ai/bot/marketplace/bots/seed-a91e4c) described as coding, issue triage and production monitoring. These are vendor-described capabilities.
Import a suitable template, inspect its instructions and adapt its workflow around a disposable repository and synthetic accounts. Test whether it can reproduce a bug, repair it, exercise the application and leave evidence another person can assess. Cursor's documented harness is a useful reference for this full loop. Keep the experiment portable by saving the task contract, checks and artifacts in formats another worker can use.
Availability checked 1 October 2026: the [Grok Bot overview and FAQ](https://x.ai/bot) lists eligible plans and weekly included usage with additional token billing. It says bots belonging to a user share a persistent computer, files, browser and logins. Separate bot names do not establish tenant isolation. An importable template does not establish free execution or a FOSS licence.
### Prefer an inspectable FOSS foundation
For a system the organization will operate, our preference is free and open-source software (FOSS) with replaceable model providers. The MIT-licensed [OpenCode](https://github.com/anomalyco/opencode) and [Pi](https://github.com/earendil-works/pi) projects are starting points for the worker harness. Pair one with the durable coordinator and controls above, then evaluate the same tasks and acceptance criteria used in the commercial experiment.
For the operational example, the [Hermes source repository](https://github.com/NousResearch/hermes-agent) provides an inspectable foundation for the persistent assistant, messaging and tool loop. Use OpenSpec to keep the workflow's requirements and acceptance criteria portable. Select the worker for the actual job, then test its connectors, permissions and recovery against the same contract.
A harness licence covers its software; model licences, inference bills, browser tooling and integrations need their own assessment. Isolation and authorization still belong in the deployed system. Keep the [Pi permission boundary](https://isaiuseful.com/tools.html.md#tool-pi-agent-harness) explicit, and compare model options through the [local model](https://isaiuseful.com/local-models.html.md) and [cloud model](https://isaiuseful.com/cloud-models.html.md) guides.
The first milestone is a bot that repeatedly closes one useful loop and leaves enough evidence to trust the result. Its natural habitat makes independent work possible. Accepted outcomes, recovery and the [90-180 day full-cost review](#roi) determine how much production scope it earns.
From the editorial to daily work · 10 October 2026
## The working world ahead is already taking shape.
A person directing more work through AI, sustained model usage and an organization learning to make the process repeatable. Four reported sprints make that possibility tangible.
### Siim Vene: four sprints with AI in daily work
[Siim Vene's](https://www.linkedin.com/in/siim-vene/) reported results compare one engineer's output with an eight-person team's total across four consecutive two-week sprints. The comparison uses the team's own story-point estimation method, alongside ccusage token and estimated-cost statistics. It offers a concrete example of the capacity an AI-assisted working loop might unlock.
#### Software-factory reference architecture
Siim Vene shares how he organizes this work in his [software-factory reference architecture](https://github.com/siimvene/software-factory) : tickets with observable acceptance examples, mechanical verification gates, cross-vendor review and a shared knowledge plane. People approve ticket readiness, merge pull requests and authorize releases. The repository distinguishes measured mechanisms from designed or proposed ones in its STATUS.md ledger. The design gives readers a concrete way to inspect his approach and adapt it to their own delivery workflows.
**Reported points vs the whole team** - 7.6× 2,993 versus 395 across all four sprints
**Reported tokens across four sprints** - 44.2B Usage volume, not newly written code
**Estimated token cost across four sprints** - $21,240 Reported ccusage estimate at model prices
**One engineer and a team of eight, using the same reported yardstick. Bars share a 0-1,800 story-point scale.**
| Sprint / dates | One engineer | Team of eight, total | Reported ratio |
| --- | --- | --- | --- |
| 178 Aug 10-23 | **570** | **86** | **6.6×** |
| 179 Aug 24-Sep 6 | **333** | **96** | **3.5×** |
| 180 Sep 7-20 | **359** | **120** | **3.0×** |
| 181 Sep 21-Oct 4 | **1,731** | **93** | **18.6×** |
#### More capacity, with sustained model usage
By sprint 181, the reported comparison reaches 18.6 times the whole team's points. Token usage rises from 1.1B to 30.9B per sprint, with ccusage cost estimates rising from $829 to $12,197. That puts the editorial's [billion-token capacity scenario](#billion-token-weeks) in a concrete working context. Actual subscription or API charges are a separate measure.
#### A signal to investigate
The output does not rise steadily, and these ratios compare one person with the entire team. Story points are local estimates, rather than a universal productivity unit. The 7.6× summary divides the four-sprint point totals; it is not an average of the displayed ratios.
Read the full token and cost ledger
**Reported ccusage statistics. Dollar figures are estimated token costs, rather than verified invoices.**
| Sprint | Estimated total | Claude estimate | Codex estimate | Tokens | Estimated $ / active day |
| --- | --- | --- | --- | --- | --- |
| 178 | $829 | Not used | $829 | 1.1B | $69 |
| 179 | $2,086 | Not used | $2,085 | 2.7B | $149 |
| 180 | $6,128 | $5,401 | $718 | 9.5B | $438 |
| 181 | $12,197 | $11,421 | $776 | 30.9B | $871 |
Claude was introduced in sprint 180; the first two sprints used Codex. Figures are preserved as reported, and the aggregate uses the Total column. Token totals do not distinguish input, output and cached context in this summary.
**Source and cost basis:** Siim Vene's supplied four-sprint summaries, redrawn here. The [ccusage documentation](https://ccusage.com/guide/) describes local token analysis and model-price cost estimates that may differ from actual billing. The $21,240 total describes reported estimated usage value; a full-cost review needs actual plan charges, infrastructure and human time.
**What this evidence establishes:** a participant-reported comparison worth testing in other workflows. The summaries do not establish matched task difficulty, engineering hours, review effort, defect rates, customer value or the use of persistent agents. They support investigating the editorial's operating model; they do not establish a causal AI effect, a transferable multiplier or a staffing conclusion. Use the [90-180 day review](#roi) to measure accepted outcomes, quality and total cost.
- [Video: Software Engineering Is Becoming Factory Engineering - Zach Lloyd, Warp](https://www.youtube.com/watch?v=tUPPVhBBcoM)
AI Engineer talk · Warp perspective · 27 September 2026
### Build the system that builds the software
Warp founder Zach Lloyd describes a software factory that connects agent triage, specifications, implementation, review, verification and monitoring, with human checkpoints for intent, risk and product quality. Human corrections can feed back into the skills used on later runs.
Alongside Siim Vene's reported sprints, the talk offers an operating model for making an individual's working loop repeatable across a team. It is a vendor's perspective, not independent evidence of productivity or ROI. Measure accepted output, human time, model cost and quality in your own workflow.
- [Read the talk and chapter guide →](https://ai.engineer/talks/tUPPVhBBcoM-software-engineering-is-becoming-factory)
### Keep people able to steer the work
> “With the factory pattern, you’re not giving up the ability to steer the agent.”
Josh Rosen · 9 October 2026
- [Software Factories for Skeptics: read the full article →](https://x.com/josharosen/status/2108616086140735976)
Rosen argues for a shared system around coding work: reusable workflows, visible progress, versioned instructions and feedback that improves the next run. That is the organizational layer between a productive individual and a durable enterprise capability.
### Give people time to learn the loop
> “if your team is too busy doing their 'normal job' to experiment with AI, you're preparing them to be replaced”
Geoffrey Huntley · 9 October 2026
- [Read the full article on AI adoption and work →](https://ghuntley.com/replaced/)
Huntley argues that managers should make room for practical AI learning and understand agent loops themselves. His employment forecasts are opinion. The practical management action is to give people protected time to experiment, compare results and share methods.
### Make judgment and the working system the advantage.
Our reading: this points toward people specifying outcomes, directing more execution through agents and managing a growing compute budget. The advantage can compound when a team retains the workflow, tests and lessons from each run. Useful capacity still depends on choosing valuable work, checking the result and keeping authority bounded. The next step is to turn an individual's effective loop into a shared, inspectable system.
- [Plan for sustained token usage →](#billion-token-weeks)
- [Specify and verify the work →](https://isaiuseful.com/thinking-with-ai.html.md#loop)
- [Build the accountable control plane →](#control-plane)
Operating model
## Persistence needs an accountable control plane.
A persistent agent retains task state and resumes after events, pauses or failures. A multi-tenant control plane owns identity, permissions, scheduling, approvals and evidence separately for each customer or organizational unit.
### Isolate every tenant
Bind authenticated users, workers, memory, retrieval, files and credentials to a tenant. Enforce this at every storage and tool boundary. A project folder or tenant ID written in a prompt does not provide isolation.
### Make execution recoverable
Persist tasks, checkpoints and approval state outside the model context. Use bounded retries, per-tenant queues and cost limits, expiring worker leases and idempotency keys for external writes. Resume against current policy after a restart.
### Deny by default
Grant named tools, targets and budgets explicitly. Broker short-lived credentials outside prompts. Separate the component that approves an action from the worker executing it, and provide a tenant-level pause and credential-revocation path.
**Implementation references:** [OWASP recommends default denial and permission checks on every request](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) . [LangGraph documents durable checkpoints and human interrupts](https://docs.langchain.com/oss/python/langgraph/interrupts) ; a checkpoint alone does not supply tenant authorization.
Human-in-the-loop (HITL)
## Ask in team chat. Resolve the decision within one hour.
This is a proposed operating policy, not a verified feature shared by the tools below. Choose the eligible voters, quorum, vetoes and timeout behavior before starting work.
1. **Propose:** the agent prepares a concrete diff or action preview, target tenant, affected systems, cost ceiling, risk, rollback and a deadline. Store a versioned request before posting its approval card to the team's Slack or Teams channel.
2. **Owner or developer responds:** an authorized approver can accept the exact action, reject it or revise the task. A rejection stops that action. A revised payload needs fresh approval; an ordinary chat reply does not change authority.
3. **Owner stays silent:** previously delegated team authority can decide. Example: five named eligible humans, one vote each, at least three affirmative votes and no designated veto before the 60-minute deadline. Bots, emoji counts and channel membership alone do not qualify.
4. **The hour expires:** close the ballot once. A passing vote releases only the approved action. Without a passing vote, the agent may continue a previously authorized low-risk fallback, such as tests, research or a local draft. Otherwise pause and escalate. Silence does not create new permission.
5. **Execute and report:** recheck tenant, policy, budget and payload version at execution. Atomically claim the decision so a timer and late reply cannot both release it. Record the outcome in the request and return a receipt to the chat.
**Example boundaries for the one-hour decision policy**
| Action | Team vote | No decision at deadline |
| --- | --- | --- |
| Research, tests or draft in an isolated workspace | Optional inside the existing task grant | Continue only within its original scope and budget |
| Bounded staging change or internal ticket update | Allowed if the accountable owner delegated it in advance | Pause the write; prepare a draft or escalate |
| Production release, payment, deletion or wider access | Does not replace a required release, finance or security approver | Remain blocked pending the required approval |
The model may explain the options and recommend a next step. Deterministic application policy counts votes and grants authority. External documents and chat content remain untrusted inputs; they cannot rewrite that policy.
**Customer feedback votes:** [OpenHeard](https://isaiuseful.com/tools.html.md#tool-openheard) lets users post and vote on requests, with roadmap, changelog, API and MCP routes. Those votes help prioritize demand. They do not authorize a production action or establish an internal Slack/Teams approval ballot. Its [official site](https://openheard.com/) describes this feedback loop.
**Transport and identity:** [verify Slack signatures and request freshness](https://docs.slack.dev/authentication/verifying-requests-from-slack/) . [Teams Adaptive Cards return actions to a bot](https://learn.microsoft.com/en-us/microsoftteams/platform/task-modules-and-cards/cards/universal-actions-for-adaptive-cards/work-with-universal-actions-for-adaptive-cards) . Neither transport defines your quorum: validate the human's current role, tenant, request ID and expiry on the server.
Evidence you can inspect
## Keep a decision ledger and test the failure paths.
Log enough to reconstruct authority and outcome without copying every secret or private conversation into a permanent trace.
**Record**
Tenant, task and request IDs; actor identity; model, tool and policy versions; payload hash; deadline; votes and vetoes; permission decision; execution result; spend and rollback reference.
**Protect**
Use append-only audit events with restricted access and tamper detection. Redact secrets, minimize personal data and set retention and deletion rules. Review the [GDPR and data-processing guide](https://isaiuseful.com/eu-gdpr.html.md) for the actual deployment.
**Prove**
Test cross-tenant reads and writes, forged and replayed callbacks, duplicate votes, stale approvals, changed payloads, timer/reply races, retries after partial writes, provider outages and the emergency stop.
Build or adapt
## Choose the worker, interface and channel after defining the controls.
Compare the worker, task coordinator, execution policy and approval channel. Each layer has a different job and a different deployment boundary.
Sorted by role in the enterprise plan. These are complementary building blocks; the shortlist is an architectural assessment, not a tested integration.
### Enterprise building blocks
Execution worker
#### Hermes / OpenClaw
Run persistent assistants inside a bounded task grant.
**Maturity** - Published releases; large communities
**Popularity** - 100,000+ stars each
**Still needed** - Your own task ledger and policy; separate trust boundaries for mixed-trust tenants.
- [Compare Hermes →](https://isaiuseful.com/tools.html.md#tool-hermes-agent)
- [Compare OpenClaw →](https://isaiuseful.com/tools.html.md#tool-openclaw-companion-apps)
Deployment details
A persistent assistant and messaging gateway. OpenClaw's security guide assumes one trusted boundary per gateway; separate gateways and credentials for mixed-trust tenants.
**Enterprise fit:** Fit as execution workers behind your own policy, credentials and task ledger. OpenClaw requires a separate trust boundary for mixed-trust tenants; neither popularity nor a command-approval feature establishes the delegated ballot.
Hermes: [100,000+ stars](https://github.com/NousResearch/hermes-agent) ; repository created July 2025; published GitHub release. OpenClaw: [100,000+ stars](https://github.com/openclaw/openclaw) ; repository created November 2025; published GitHub release.
Task coordinator
#### Coding harness + coordinator
Put bounded coding tasks behind a durable, reviewed queue.
**Maturity** - Depends on the chosen components
**Popularity** - No single project score
**Still needed** - Build tenancy, checkpoints, budgets, approval state and idempotent retries.
- [Compare coding harnesses →](https://isaiuseful.com/thinking-with-ai.html.md#tools)
Deployment details
Bounded code tasks behind a reviewed queue. Your coordinator owns tenancy, checkpoints, identity, approvals and retries. Select it on required controls and total cost.
**Enterprise fit:** Strong fit when the coordinator implements tenant isolation, a durable decision ledger and tool authorization. The maturity of a coding harness does not transfer automatically to your custom coordinator.
No single repository or popularity score: assess the selected harness and coordinator separately.
Execution policy and audit
#### OpenBot
Inspect the gateway that decides and records tool actions.
**Maturity** - Alpha with a published release
**Popularity** - 1,000-10,000 stars
**Still needed** - Enable sign-in; test tenant boundaries, durable decisions and bypass paths.
- [Compare OpenBot's deployment boundary →](https://isaiuseful.com/tools.html.md#tool-copilotkit-openbot)
- [OpenBot source and security configuration →](https://github.com/CopilotKit/OpenBot)
Deployment details
Give coworkers separate browsers and files behind a gateway that documents policy evaluation and audit recording before execution. This alpha defaults to a single administrator without sign-in. Configure authentication before sharing it and keep lower-level computer endpoints private.
**Enterprise fit:** The most directly aligned action-policy and audit reference here. Pilot authenticated gateway enforcement and isolated computers, then test tenant boundaries, durable decisions and bypass paths. The default single-admin mode must be disabled.
[1,000-10,000 stars](https://github.com/CopilotKit/OpenBot) ; repository created August 2026; published GitHub release.
Slack / Teams approvals
#### OpenTag
Adapt resumable approval cards and write interrupts in team chat.
**Maturity** - Channel starter with published releases
**Popularity** - 1,000-10,000 stars
**Still needed** - Implement eligible voters, quorum, veto, expiry and atomic action release.
- [Compare OpenTag's channel setup →](https://isaiuseful.com/tools.html.md#tool-copilotkit-opentag)
- [OpenTag source and approval examples →](https://github.com/CopilotKit/OpenTag)
Deployment details
The Channels SDK starter connects an AG-UI/LangGraph agent to team chat with native results and demonstrated approval gates for Linear and Notion writes. Its quick start uses a managed channel; operating your own runner is a separate choice. Test approver identity and tool scope in the actual workspace.
**Enterprise fit:** The closest channel reference for the proposed workflow: documented write interrupts and resumable approval cards. Implement eligible voters, quorum, veto, expiry and atomic execution separately; verify managed delivery and approver identity.
[1,000-10,000 stars](https://github.com/CopilotKit/OpenTag) ; repository created June 2026; published GitHub release.
Reviewed 5 October 2026. Star bands measure attention, not installations or enterprise reliability. Every route still needs the [tenant control plane](#control-plane) and [delegated decision policy](#approvals) .
Explore workspaces, harnesses and browser-use pilots
### Focused pilots and interface references
These projects can inform a bounded pilot or interface design. Their documented boundaries and short public histories do not establish production readiness for this operating plan.
Execution-worker pilot · checked 10 October 2026
#### OpenHuman
Evaluate a compact Rust harness behind your own task and permission boundary.
**Maturity** - Early beta
**Licence** - GPL-3.0
**Still needed** - Tenant isolation, enforceable grants, durable approvals and restart tests.
- [Compare features, licence and benchmark limits →](https://isaiuseful.com/tools.html.md#tool-openhuman)
Deployment details
Its memory and fleet measurements are maintainer evidence. Keep inference and connector costs in the full-cost pilot; a lightweight harness does not establish safe multi-tenant operation.
Browser-use pilot · checked 10 October 2026
#### Hark Handoff
Study long browser tasks with a dedicated virtual computer.
**Maturity** - Vendor research preview
**Deployment** - Hark describes a browser, filesystem and terminal per request.
**Still needed** - Verify access, account grants, action approvals, audit and recovery.
- [Hark's research preview, recordings and evaluation method →](https://hark.com/articles/introducing-hark-handoff)
Deployment details
Hark demonstrates shopping, reservations, recruiting and research through connected accounts. Its benchmark presentation mixes leaderboard results with tests in Hark's own harness. Vendor recordings and scores do not establish enterprise authorization, tenant isolation or measured ROI. A dedicated computer still needs narrowly scoped account authority and explicit approval for consequential writes.
Specialist interface
#### OpenDots (CopilotKit)
Adapt pages, specialist roles and reviewed learning workflows.
**Maturity** - Single-owner template
**Popularity** - 1,000-10,000 stars
**Still needed** - Replace the single-owner identity model and verify connected services.
- [Compare OpenDots and its service boundaries →](https://isaiuseful.com/tools.html.md#tool-copilotkit-opendots)
- [OpenDots source and verification notes →](https://github.com/CopilotKit/OpenDots)
Deployment details
Combine a page workspace with text, calls, Slack and scheduled work. The README describes a single-owner starting point; shared editing and automatic multi-Dot delegation remain further work. Slack, spoken compute delegation and cloud Learning delivery still need connected-service verification.
**Enterprise fit:** Useful page, specialist and learning interfaces. Its single-owner identity model needs replacement for multi-tenant use; specialist roles and separate conversations do not establish separate customer authority.
[1,000-10,000 stars](https://github.com/CopilotKit/OpenDots) ; repository created September 2026; no published GitHub release.
Personal-agent interface
#### OpenMuse
Adapt plans, browser takeover, receipts and recovery UI.
**Maturity** - Alpha personal-agent template
**Popularity** - 1,000-10,000 stars
**Still needed** - Connect the interface to your tenant authorization and decision ledger.
- [Compare OpenMuse's runtime requirements →](https://isaiuseful.com/tools.html.md#tool-copilotkit-openmuse)
- [OpenMuse source and feature inventory →](https://github.com/CopilotKit/openmuse)
Deployment details
An alpha personal-agent app for phone and web with task plans, browser takeover, approvals, receipts and recurring checks. Its server and workers are useful recovery references. Rich Threads, live model reasoning and Google connections need separate configuration; sample flows do not verify enterprise isolation.
**Enterprise fit:** Useful plans, takeover, receipts and recovery UI. Adapt those surfaces to your control plane; the personal-agent design and configured sample flows do not prove multi-tenant authorization or the delegated ballot.
[1,000-10,000 stars](https://github.com/CopilotKit/openmuse) ; repository created September 2026; no published GitHub release.
Task orchestration
#### Comma
Inspect persistent tasks and event-watching loops in a bounded pilot.
**Maturity** - New public personal-agent project
**Popularity** - 100-1,000 stars
**Still needed** - Prove tenant enforcement, approvals and recovery across its service stack.
- [Compare Comma's operating requirements →](https://isaiuseful.com/tools.html.md#tool-comma)
Deployment details
AGPL-3.0, persistent tasks and event-watching loops; hosted or self-hosted. Assess device authority, provider data paths and the multi-service operating cost. Task persistence does not establish the proposed voting policy.
**Enterprise fit:** Inspect its persistent-task and event-loop design in a bounded pilot. Treat tenant enforcement, delegated approvals and recovery guarantees as acceptance tests; the public history is too short to infer operating maturity.
[100-1,000 stars](https://github.com/AFK-surf/Comma) ; repository created September 2026; no published GitHub release.
Local workspace
#### Jelly
Explore local persistent agents for a trusted operator.
**Maturity** - Early local workspace
**Popularity** - Under 100 stars
**Still needed** - Host isolation and external authorization before handling mixed-trust tenants.
- [Compare Jelly's execution boundary →](https://isaiuseful.com/tools.html.md#tool-jelly)
Deployment details
MIT, local persistent agents on the Pi harness. A trusted-user workspace with host-level file and shell permissions, without per-tool approval. Add isolation and external policy enforcement.
**Enterprise fit:** Useful for a trusted operator on an isolated host. Host-level tools and unsandboxed patch paths make it a poor direct foundation for mixed-trust tenants; external authorization and isolation are substantial work.
[Under 100 stars](https://github.com/dctanner/jelly) ; repository created September 2026; no published GitHub release.
Workspace prototype
#### Open Dots (Anil-matcha)
Explore interface and connector patterns.
**Maturity** - Prototype
**Popularity** - 1,000-10,000 stars
**Still needed** - Redesign the documented multi-user and hostile-web isolation boundaries.
- [Compare the Open Dots prototype →](https://isaiuseful.com/tools.html.md#tool-open-dots)
Deployment details
MIT, inspectable workspace with approvals and connectors. Maintainers label it a prototype: multi-user hosting and hostile-web isolation are not production ready.
**Enterprise fit:** Use for interface and connector exploration. The documented multi-user and hostile-web limitations exclude it from the production shortlist until those boundaries are redesigned and tested.
[1,000-10,000 stars](https://github.com/Anil-matcha/open-dots) ; repository created May 2023; no published GitHub release.
Evidence, maturity and deployment notes
Repository creation dates describe the public repository, not necessarily the current product's age. A missing GitHub release does not mean there are no tags or deployments. Release labels and alpha/prototype descriptions come from maintainers; enterprise-fit judgments are editorial. This review does not establish independent production outcomes or completion of the control requirements.
Runtime documentation checked 1 October 2026: [OpenClaw security](https://docs.openclaw.ai/gateway/security) , [Jelly](https://github.com/dctanner/jelly) , [Comma](https://github.com/AFK-surf/Comma) and [Open Dots](https://github.com/Anil-matcha/Open-Dots) . Product documentation is evidence of described capabilities and limitations, not independent assurance.
CopilotKit project documentation checked 4 October 2026. These are vendor-maintained templates and described controls, not independent production assurance. CopilotKit's **OpenDots** is separate from the [Open Dots prototype by Anil-matcha](https://isaiuseful.com/tools.html.md#tool-open-dots) .
**Define the boundary before deploying.** AG-UI connects the agent and interface; it does not grant execution authority. Self-hosting an app does not establish that Threads, Learning, model inference, voice or channel delivery stay inside your infrastructure. Map each configured service, cost and data path. A saved conversation is not a durable task ledger, and an approval card does not implement the [one-hour delegated decision policy](#approvals) . Keep tenant isolation, default denial, expiry, explicit rejection and restart behavior in enforceable application policy.
**Treat learning as a reviewed change.** OpenDots documents conversation evidence routing into Learning containers and reviewed publication of skills. Version and test a proposed skill before granting it to workers; keep learned instructions separate from policy and credentials. Test deletion and retention across conversations, memory, skills and audit records using the [personal-data guide](https://isaiuseful.com/eu-gdpr.html.md) .
**Adjacent components:** [Paperclip](https://isaiuseful.com/tools.html.md#tool-paperclip) adds an agent-management route with tasks, routines, approvals and budgets; its recorded-spend enforcement can lag in-flight usage. [Hindsight](https://isaiuseful.com/tools.html.md#tool-hindsight) supplies a memory service, and [treg](https://isaiuseful.com/tools.html.md#tool-treg) supplies a tool/credential proxy with a restricted service licence. They solve different layers. Compare accepted outcomes and full operating cost in the [90-180 day review](#roi) .
A decision window, not a promise
## Earn production scope over 90-180 days.
Choose one recurring workflow and compare accepted outcomes with its human baseline. A busy agent, token savings or a faster draft alone does not establish ROI.
**Days 0-30**
Measure baseline volume, completion time, quality and cost. Run in shadow mode; agree on acceptance, incident and cost thresholds before seeing results.
**Days 31-90**
Pilot bounded actions with human review. Count accepted work, review minutes, approval wait, rework, failures and all operating costs. Stop or redesign if quality or controls fail.
**Days 91-180**
Scale only after stable quality, tested recovery and positive net value. Recheck each new tenant and workflow. Review avoided costs separately from capacity that has not become cash savings.
**Full-cost ROI = (realized benefit - total cost) / total cost.** Total cost includes setup, models, infrastructure, integration, human review, security, maintenance and incident recovery. Track cost per accepted task alongside quality and escalation rate.
**Illustration, not measured evidence:** 400 accepted tasks/month saving 15 minutes at €50/hour yield €5,000/month of capacity value. If monthly review costs €1,500 and all other recurring costs €1,000, net capacity value is €2,500/month. A €7,500 setup pays back in three months if that capacity is realized. Over six months: €30,000 benefit, €22,500 total cost, €7,500 net benefit and 33% full-cost ROI. Unused capacity lowers the realized benefit.
- [Build repeatable adoption](https://isaiuseful.com/adoption.html.md#engineer)
- [Review software delivery controls](https://isaiuseful.com/thinking-with-ai.html.md#security)
- [Compare the tools](https://isaiuseful.com/tools.html.md)
- [Work through the ROI guide](https://isaiuseful.com/guides.html.md#ai-roi)