A coding agent can be impressive in a terminal and still be a fragile service.
The failure usually is not the model. It is the runtime around it: where the process runs, which credentials it can reach, what state survives a restart, how tool calls are observed, and what happens when a job times out halfway through a write.
Here is the pre-flight checklist I use before treating an OpenClaw-style agent as deployable.
1. Separate the agent runtime from application traffic
Do not let the agent process share the same failure domain as the public app unless there is a clear reason. Give it a separate service boundary, resource limits, health checks, and an explicit egress policy.
That makes a runaway loop or dependency outage easier to contain. It also makes rollback less dramatic: replace the worker without taking the user-facing application with it.
2. Scope credentials per capability
A general-purpose agent should not inherit a developer shell, a full cloud profile, or every repository secret.
Start with a capability table:
- read-only repository access
- bounded issue and pull-request access
- narrowly scoped deployment access
- separate approval for destructive actions
Treat the tool contract and the credential scope as one design. A read-only tool backed by a write-capable token is not read-only in practice.
3. Put durable state outside the process
If a restart loses the conversation, job ID, checkpoint, or idempotency key, recovery becomes guesswork.
Persist at least:
- workflow and step IDs
- the last accepted tool result
- pending approvals
- retry count and backoff state
- idempotency keys for mutations
- the model and prompt version used for the step
The agent can keep a working context in memory, but recovery-critical state should survive a process crash and a host replacement.
4. Make external writes observable and verifiable
A final message saying “done” is not evidence. For every side effect, record the request, the raw response, and an independent read-back when the API supports it.
A useful write path is:
- create an operation ID and idempotency key;
- execute the mutation;
- persist the raw response before summarizing;
- read the target resource by the returned ID;
- fail the workflow if the resource is missing, duplicated, or owned by the wrong repository or account.
This turns a confident hallucination into a deterministic failure that the harness can retry or escalate.
5. Bound cost and fan-out
Set limits before the agent starts, not after the bill arrives:
- maximum model calls per task
- maximum tool calls per step
- maximum parallel workers
- timeout per tool class
- retry budget
- spend ceiling
- escalation condition when the budget is exhausted
A cheaper model can still be the expensive choice if it needs many retries or produces more human rework. Measure accepted outcomes, not just token price.
6. Define rollback and recovery as normal paths
Test the awkward cases deliberately:
- the host restarts after a successful mutation but before the response is stored;
- a tool times out after the server commits the change;
- a worker resumes with an expired credential;
- two workers pick up the same job;
- a deployment is healthy but the agent's state store is unavailable.
If the only recovery plan is “ask the model what happened,” the system is not observable enough yet.
A small deployment decision rule
I only call the runtime ready when I can answer these questions without looking at the agent's prose:
- Where is the process running?
- Which identity is it using?
- What state will survive a restart?
- Which writes can be retried safely?
- How do I prove an external effect happened?
- What is the rollback path?
For teams that want a practical place to host and deploy this kind of workload, Ampere is one option to evaluate: https://ampere.sh
The important part is not choosing a particular host. It is making the runtime, identity, state, cost, and recovery boundaries explicit enough that the model is not the only component making decisions.
What is the first control-plane check you add before shipping an agent?
Top comments (0)