Writing Agent Instructions That Run Without Follow-Up Questions
Build identity and clear decision criteria into your prompt before execution starts.
A system prompt runs on three layers. Skip one, and the whole thing falls apart the first time reality doesn't match the happy path.
The character layer is identity: who the agent is, its tone, its values, its boundaries. This layer rarely changes, and it shapes behavior on its own, without a written rule for every edge case that comes up. The operational layer covers workflows, constraints, tool access, and decision criteria; it tells the agent what to do and when. The format layer defines what a finished output looks like, so the agent doesn't hand back a ten-page narrative when the task called for four bullet points.
Naming the agent and giving it a real identity matters more than most people expect. Here's the position worth stating plainly: a strong character beats a long list of rules almost every time. Fifty scattered instructions force a lookup on every turn. A well-built identity lets the agent draw conclusions the way an employee who actually understands the job does, without flipping through a policy manual for each decision. That's the gap between an agent that handles situations nobody wrote down and one that stalls the moment it hits something not on the list.
Underneath all this sit five patterns agents lean on: tool use, reflection, ReAct, planning, and multi-agent collaboration. ReAct earns special mention, since it's the most instructable of the five. The cycle, reason, act, observe, re-reason, gets written directly into the instruction as a loop, giving the agent somewhere to go when something breaks, rather than running into a dead end.
Before execution starts, the operational layer has to answer four questions. What's the goal, and how does the agent know when it's done? Which tools can it use, and under what conditions? What happens when a step fails? And what's the stopping condition, including what should never count as one?
How to write decision criteria that prevent clarifying questions
Clarifying questions get treated like a quirk of the model. Really, the agent hit a decision point, found no criteria in the instruction, and punted the ambiguity back to a human instead of resolving it on its own.
The fix is a decision tree written straight into the instruction: if X, do A; if Y, do B; if neither, do C and flag it. That structure alone wipes out most of the pauses where an agent would otherwise stop and ask.
Here's where most people get it backwards on context: more information is not automatically better. Dumping in everything the agent could possibly need is the more common failure, ahead of leaving something out. Hand an agent every fact it could conceivably use instead of exactly what its role requires, and the actual decision criteria get buried under noise it has to wade through first. The instinct to over-provide feels safe. It costs more than it saves.
Scope control belongs in this same bucket. If a task turns out bigger than expected, the instruction should tell the agent to finish the first few items, summarize what's left, and stop, rather than forcing through the whole thing. This heads off a failure mode worth naming directly: the path-of-least-resistance problem. Without explicit constraints, an agent defaults to whatever's easiest to generate, and that's often the longest, priciest, or least useful version of the output.
Numbered workflow steps cut error rates for a simple reason: a specific sequence removes the need for the agent to decide what comes next at every turn. Format deserves a mention too, since it works as a decision criterion in disguise. Defining the deliverable format up front answers "how should I present this?" before the agent ever has to ask.
Writing tool-use rules that tell the agent when not to act
Right after vague roles, the most common failure is dumping too many tools on an agent with zero guidance about which one applies when.
Tool instructions need to cover four things: which tools are actually available, distinct from what merely exists somewhere in the environment; under what conditions each one gets called; what the agent does when a tool call fails or returns something unexpected; and hard stops, actions the agent must never take no matter what it infers from context.
This is where MCP, the Model Context Protocol, changes the picture. Built originally by Anthropic and now stewarded by the Linux Foundation, MCP standardizes how agents connect to tools. Tool selection is quietly becoming part of the prompt itself, alongside its life as a separate infrastructure concern handled elsewhere. With a large and growing catalogue of connectors available, the instruction has to say which tools from that catalogue are actually in scope for a given role. Skip that step, and the agent treats the entire catalogue as fair game. That's exactly the failure mode nobody wants running loose on an unattended job at two in the morning.
Composio shows what this looks like at scale. A single MCP endpoint can give an agent authenticated access to a wide catalogue of business app integrations, Gmail, Slack, GitHub, Notion, and plenty more, with OAuth, token refresh, and credential lifecycle handled by the platform instead of whoever wrote the instruction. Once authentication stops being the instruction writer's problem, the job shifts toward defining exactly when the agent is, and isn't, allowed to use what it's been given. Infrastructure handles access; the instruction handles judgment.
Error handling and stopping conditions as first-class instruction elements
Most instruction failures don't show up at step one. They show up mid-workflow, when something unexpected happens and the agent has no path forward written anywhere.
Error handling in an agent instruction takes the form of plain prose describing what happens when a tool call returns nothing or throws an error, when a required piece of information is missing from context, when the task turns out to sit outside the agent's scope or permissions, or when two rules in the instruction seem to contradict each other.
Stopping conditions are the piece people skip most, and skipping them breaks in one of two directions. The agent either stops too early, treating any obstacle as a signal that it's done, or it runs indefinitely, treating the absence of an explicit finish line as permission to keep going. Neither failure is rarer than the other; they're opposite symptoms of the same missing sentence. Write stopping conditions as positive statements: the task is complete when X is true and Y has been delivered. A clear picture of what success looks like does more work here than any list of things that shouldn't happen.
The reflection pattern helps close the gap. Instructing the agent to check its own output against the original goal before declaring itself done catches a large share of drift before a user ever sees it.
Good error handling reads like this, concretely: "If the API returns an error, log the message, skip that item, move to the next one, and include a summary of skipped items in the final output." Nothing left to clarify there. That's the bar.
How the choice of agent runtime shapes what instructions must cover
Agent runtimes split into two practical camps, and treating them the same is the mistake that shows up most often in production. Fix that one thing first, before touching anything else in the instruction.
Coding-first agents, think Claude Code or Codex, are built for repository understanding, file editing, running tests, and shipping code. Instructions for these need to cover repository scope, exactly which files can be edited, and what counts as passing the test suite. Persistent workflow agents, like OpenClaw or Hermes, are built for always-on automation: memory that carries across sessions, messaging channels, model-agnostic orchestration. Their instructions need to cover trigger conditions, how memory gets handled, and how work passes between sub-agents.
OpenClaw acts as a meta-orchestrator, dispatching coding agents like Claude Code or Codex as sub-tasks. Its instruction has to define what the agent does directly, what it hands off, and how it collects and reconciles the results that come back.
Hermes complicates things differently. Because it auto-generates skill documents across sessions, its instruction has to account for what the agent is allowed to learn and hold onto over time, alongside what it should do on any given day.
There's a governance line here that's easy to miss and expensive to ignore. Message-driven harnesses like OpenClaw and Hermes run on the operator's own infrastructure, under the operator's own data policies. Cloud agents like Codex send code out to vendor-managed environments, and that's worth sitting with for a second: code and credentials that leave the operator's infrastructure don't come back. For anything compliance-sensitive, the instruction has to reflect which regime actually applies. The rule of thumb that holds up in production: use a coding agent as a desk-side collaborator for active development sessions, and save persistent agents for scheduled or trigger-based work that has to run while nobody's watching.
What a production-ready instruction looks like across deployment environments
A production-ready instruction is dense and picky about what it includes. Every sentence either defines identity, constrains behavior, sets a tool rule, or handles a failure mode, with no filler or decoration.
A complete instruction breaks into six blocks. An identity block names the agent and its role, including what it's not responsible for. A context block covers what it knows about the environment, the user, and the task, and just as important, what it should never assume. A workflow block lays out numbered steps, branching criteria, and scope limits. A tool block lists available tools, when each one applies, and what happens on failure. An output block defines format, length, and what "done" actually looks like. A stopping and escalation block spells out completion conditions and what triggers a handoff or a flag to a human.
Where an agent has access to tools like Gmail, Slack, or GitHub through a platform like Composio, the tool block needs to say exactly which connections are in scope and what authorization the agent can assume it has. Leave that out, and the agent guesses at what it's actually allowed to touch. That's a bad thing to leave to chance once real credentials are involved.
Always-on deployment adds one more layer that's easy to underweight. For agents running on cron schedules or persistent triggers instead of a session a person kicked off directly, stopping conditions and error logging matter more, because no one's watching the run happen in real time. Managed hosting platforms that handle uptime, sandboxing, and integration plumbing take a lot of that operational weight off the instruction writer's plate. Agent37, for instance, is a cloud hosting service for always-on agents where deployment requires no server setup at all. Infrastructure defaults get handled elsewhere, so the instruction itself can focus entirely on behavior, decision criteria, and domain logic.
The test for whether an instruction is actually finished is simple, and it's the only test that matters. Hand it to the agent with no other context and a realistic task, then watch what happens. If it stops to ask a clarifying question, that's a missing decision criterion. Find it, add it, and run the test again. Keep going until the agent gets through the workflow without asking anything at all.
