Persistent agents in production.

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 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 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 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 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 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 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 and personal-data guide 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. 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 and decision ledger 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 describes internal engineering bots reproducing UI bugs and handing fixes to other bots. Its engineering marketplace offers templates to import, including a SWE bot by Cursor 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 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 and 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 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 explicit, and compare model options through the local model and cloud model 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 determine how much production scope it earns.