One Prompt Doesn’t Make an AI Agent Ready for Work

Most people set up an AI agent by writing one good prompt and turning it loose. One clever prompt is how agents end up sending the wrong email, spending real money, or publishing something nobody approved. If you are about to put an agent on a live workflow this week, the prompt is not the thing standing between you and a mess to clean up.

A prompt tells an agent what to do once. A job tells it what it owns, what it is allowed to touch, and what has to be true before its work goes live. Before an agent touches a live workflow, it should pass a short contract, nine fields that turn a clever demo into something you can run.

Here is the nine-field contract I run every agent through before it goes live, walked on one real bot, so you can ship agents that help instead of ones you babysit.

TL;DR

• A prompt tells an agent what to do once; a contract gives it a standing job with limits, and only the contract makes an agent safe to run live.
• Nine fields make an agent ready: job, trigger, inputs, authority, cap, proof, readback, escalation, and owner. A single prompt gives you none of them.
• Roll it out on one agent with one owner, gate anything that spends money or publishes, and widen access only after the logs earn it.

Why One Prompt Isn’t Enough

An AI agent runs a job on its own. It reads inputs, calls tools, makes a decision, and acts on that decision, sometimes before anyone sees the output. A prompt is a one-time instruction. A contract is a standing job with limits. It states what the agent owns, when it fires, what it can touch, and when it has to stop and ask a human.

I treat every agent like a new hire. It earns access one stage at a time.

Without a contract, you get an agent that can technically do the task but has no limit on scope, budget, or publishing rights. None of that is readiness. It is a liability with a chat interface.

The Nine Fields Every Agent Needs Before It Runs

An AI agent needs a clear job and trigger, defined inputs, explicit authority and a hard cap on what it can do, a proof step, a readback of what it did, an escalation path, and a named human owner before it is ready to run a live workflow. A single prompt gives you none of these.

Here is each field, defined once.

• Job. The outcome the agent owns, stated in one sentence. Not “help with content” but “draft a trial-offer email for every new free-tier signup.”
• Trigger. The event that starts it. A new CRM row, a Slack message, a calendar date. No trigger means it runs whenever, which is never what you want.
• Inputs. The exact data it can read. If it needs a first name and a plan type, list those two. Anything not listed is off-limits.
• Authority. What it is allowed to do, written as a whitelist. Send an email, update a sheet, post to a channel. Everything else is denied by default.
• Cap. The hard ceiling on what it can spend, send, or publish in a set period. No cap means unlimited exposure.
• Proof. The check it runs on its own output before acting. A format regex, a word-count limit, a sentiment score above a line. Something testable.
• Readback. The log it writes after every action. What it did, what data it used, what it produced. You need this for audits and debugging.
• Escalation. The rule for when it stops and asks a human. Confidence under 70 percent, or a request outside its authority, gets flagged.
• Owner. One named person accountable for the output. Not a team. Not a channel. One human.

A Worked Example: A Trial-Content Bot

Theory is easy. Filling in the fields on a real bot is where teams stall. Here is a marketing agent I run, with every field completed.

The bot drafts short follow-up emails for people who started a free trial but have not activated after 48 hours.

• Job. Draft a one-paragraph activation reminder for each inactive trial user.
• Trigger. The CRM flag flips to inactive_48h.
• Inputs. First name, product tier, signup date. Nothing else.
• Authority. Write a draft and drop it in a review queue. It cannot send.
• Cap. 50 drafts a day. Past 50, it stops and logs a warning.
• Proof. The draft must be under 80 words, include the first name, and carry no pricing or discount language.
• Readback. Each draft is logged with a user ID, a timestamp, and a word count to a shared sheet.
• Escalation. If a required field is missing, it skips that user and alerts me.
• Owner. Me. One person, one Slack DM when something breaks.

Notice what the bot cannot do. It cannot send email. It cannot see billing data. It cannot offer a discount. Every boundary is set before it writes a word.

You should be able to read a filled-in contract in under sixty seconds and know exactly what the agent will and will not do.

Where Agents Break Without a Contract

An agent is not a script, and most teams still run it like one. Scripts repeat. Agents interpret, choose, and act, so when a field is missing the failure mode is predictable.

No cap? The agent sends 4,000 emails on a Saturday because nobody told it to stop at 50. No escalation rule? It guesses through edge cases and gets half of them wrong. No owner? The broken output sits in a queue for three days because everyone assumes someone else is watching.

What happens when you skip the cap field? The agent does exactly as much damage as its permissions allow.

Agents break when they can send, publish, delete, or spend without a human gate. Anthropic’s engineering team makes the same case for building agents with explicit tool boundaries and constraints, which is what the authority, cap, and escalation fields put in writing. A point founders building with agents keep making is that the setups that hold up run many narrow agents, each boxed into one job, rather than one bot that can touch everything.

Autonomous agents are already changing how marketing teams operate, and agentic AI in digital marketing shows where they fit across the funnel. A contract does not prevent every failure. It makes every failure trace back to a specific missing field, so you fix it once instead of chasing symptoms.

How to Roll This Out

Do not fill in nine fields for twenty agents on day one. Start with one agent, one workflow, one owner.

Pick the agent closest to production and fill in the contract. If you cannot complete all nine fields, the agent is not ready, and knowing that is the point. The contract is a forcing function, not paperwork.

Put a human gate on anything that spends money or publishes. No exceptions for the first thirty days. After that, widen the cap and authority from the readback logs, not from a gut feel.

One owner per agent. If the owner leaves, the agent gets paused until a new owner takes it. Orphaned agents are how things break at 2 a.m. on a holiday weekend. Building this kind of agent governance into a broader operation is the work our marketing consulting team does with teams scaling past their first bot.

The industry will keep shipping faster models and flashier demos. None of it matters if the agent does not know its own limits. Speed without a contract is just faster chaos. Fill in the contract before you write the prompt, every time. Every agent I have shut down failed on a missing field, not a bad model.

Ready to ship agents that run without burning your team’s time? Our AI marketing agency gets your agent contracts right before you launch.