Requesting and Building Agents Like You Have a Dev Team

Here is a scene I run into constantly. A sales team wants an agent that automatically checks space and rates. They tell a technical colleague, verbally, a few sentences about what they want. The colleague says “sure, I’ll get to it.” Two weeks later the agent appears. The business team looks at it: wrong ports, missing fields. Back for another two weeks.

The problem is not technology. The requirement was never actually raised.

Asking AI for a change is the same as asking your dev team

Companies with a dev team long ago taught their business people how to work with it: write a requirement, explain what you want, review it, test it, ship it, and follow a change process for modifications.

That discipline took years to build. But when AI agents arrived, everyone forgot it — as if “you can just talk to AI” meant we were back to verbal requests and random edits.

Building an agent and raising a ticket with your dev team are the same thing: same change discipline, different executor. The executor is now an agent instead of a person.

What the business side needs to do is move the familiar requirement workflow onto the agent:

• Write the requirement: who this agent is, what it does, which rules it follows, what it must never do
• Get a review: changes are not decided by one person alone; someone who knows the domain checks them
• Keep a record: every change is logged — who changed it, what changed, why
• Roll back: if a change breaks something, you can return to the previous version instead of panicking

Why this process cannot be skipped

It feels like overhead: an agent, and you want a process just to edit a prompt?

You will understand once the agent touches real business. An agent that auto-replies to customers — if someone casually edits its prompt to “reply more warmly,” it might start promising sailing dates nobody approved. With no record, you cannot even find out who changed it and to what.

This is not a scare story. I have seen too many incidents where “the agent was fine yesterday and started talking nonsense today.” Everyone stares at each other; the only move is to turn it off and hope.

If every change went through requirement → review → record, the scene never happens. You check the log, find the change that introduced the problem, roll back, and it is resolved in ten minutes.

Walk one freight scenario through the process

Say your company wants a quoting agent: when a customer inquiry arrives, it looks up matching space and rates and drafts a quote.

Following the dev-team requirement workflow, the ticket looks like this:

1. What we want: on an inquiry, look up matching space and pricing from the rate table and draft a quote
2. Boundaries: only quote from contracted rates, never promise final pricing; if nothing matches, say “needs manual confirmation” — never invent
3. Review: the operations lead checks fields, wording, and boundaries
4. Acceptance: run 10 real inquiries, check accuracy and format
5. Record: archive the config and prompt; log every later change
6. Rollback: if a customer reports a wrong price after launch, roll back to the previous version first, then investigate which change caused it

After this, you have not just an agent — you have an engineering file you can check, edit, and revert.

What if your company has no dev team

“You have no dev team, so does this still apply?”

Yes — and it applies even more. With no dev team, nobody backs you up when things go wrong. If the agent drifts, the business absorbs the damage. Records and rollback are not overhead; they are survival.

A small company does not need a complex system. It needs one plain habit: every agent change goes through request → record → rollback. Even a change note stored in a shared folder beats “changed and forgot” a hundred times over.

Scope and open questions

This approach assumes your agent will touch real business and be relied on. If you are building a throwaway tool for yourself that you will not use tomorrow, the full process is unnecessary — but keep a backup anyway.

What I have not fully solved: how to make raising the requirement itself effortless, so the process never feels heavier than the work. Templates help, but we are not at “friction-free” yet.

Continue reading: how to keep production agents versioned with PRs; build an AI employee without code; and write the job description first.