An OpenClaw install is not a chatbot you drop on a page. It is an agent that takes actions in your systems. That means the install is only half the work. The other half is the runbook that tells you, and the agent, what it is allowed to do when things go sideways.
People ask what they actually get. So here is the real thing, not the brochure.
The runbook is the deliverable, not the demo
A demo shows the agent answering a question. The runbook shows what happens at 2am when the API it depends on returns a 500.
Most agent projects skip this part. They ship the happy path and call it done. Then the agent confidently does the wrong thing, and nobody can explain why.
We treat the runbook as the contract. It defines triggers, tools, guardrails, and escalation. If it is not in the runbook, the agent does not do it.
Triggers: what wakes the agent up
First section names every entry point. A support email hits a shared inbox. A webhook fires from your billing system. A user types in a widget.
Each trigger gets a one-line definition and a payload shape. No ambiguity about what the agent receives.
This matters because most production bugs are input bugs. A field you assumed was always present shows up null. The runbook lists what is guaranteed and what is not.
Tools: what the agent can touch
Next we list every tool the agent can call. A read query against your knowledge base. A write to your ticketing system. A refund call to Stripe.
Each tool has a blast radius. Read-only tools are safe to run without review. Write tools that move money or change customer state get a gate.
We mark which tools are reversible and which are not. Sending an email is not reversible. The runbook treats those tools as load-bearing and slows them down on purpose.
Guardrails: where the agent stops
This is the section a sharp CTO actually reads. It says what the agent will not do, and what happens when it hits a wall.
The agent does not guess past its confidence. When the retrieval comes back thin, it says it does not know and hands off. That single rule prevents most of the embarrassing answers.
We also cap actions per session and per user. An agent stuck in a loop is a bill and a liability. Hard limits sit in the runbook, not in someone's memory.
Escalation: the human path
Every agent needs a clean exit to a person. The runbook defines the handoff: when it fires, who gets it, and what context travels with it.
A support agent we built answers in 12 minutes, down from 4 hours. The speed is not the point on its own. The point is that the cases it cannot handle escalate fast, with the full thread attached, so the human is not starting cold.
That is the deal. The agent clears the volume it can clear. The hard 10 percent reaches a human faster than before, not slower.
Failure modes we write down
We name the ways it breaks before it breaks. Upstream API down. Rate limit hit. Malformed input. Ambiguous request. Prompt injection in user-supplied text.
For each one, the runbook says the expected behavior. Degrade to a safe default. Retry with backoff. Refuse and escalate. Log and move on.
You should be able to read the failure section and predict what the agent does in a bad hour. If you cannot, the runbook is not finished.
Why we hand it over
You own the code and you own the runbook. We exit. The whole point is that your team can operate this without us on retainer.
That is how we work across the board. Fixed price every time, you own the code, we exit. OpenClaw Installation starts at $5K, and the runbook is part of it, not an upsell.
We are a 2-person team, ex-AWS Federal SA on the build. We shipped 10 production products in 7 months by being disciplined about exactly this kind of operational detail. The agent is easy. The runbook is the work.
If you want an agent in production that your on-call engineer trusts, see pricing or grab a free 30-minute call at book a call.