AI agent development

A chatbot answers a question. An AI agent finishes the task. It looks up a record, decides against a playbook, acts in a system of record, and confirms the result. If the only output is a paragraph of advice, you built a writer, not an agent.

The useful ones update a CRM, file a ticket, process a refund, match an invoice, or schedule a follow-up inside guardrails you can read. The commercial shape of that work is AI agents. This post is how to pick the first workflow, how to keep the agent from doing expensive things alone, and what has to exist before it touches production.

If you cannot name the procedure, you are not ready for an agent. You are ready for a use-case ranking.

Pick one high-volume process with a written playbook

Agents pay for themselves on volume plus a definable procedure. They fail on a moonshot with no owner.

Good first workflows:

• Routine support cases with a known resolution path.
• Invoice matching and order status.
• Claims intake that already has a checklist.
• CRM hygiene: missing fields, follow-up drafts, stale opportunities.

Bad first workflows:

• "Be the assistant for the whole company."
• Anything that needs a new source of record.
• A process nobody can write as a one-page playbook.
• A process that happens twelve times a year. Count the labor hours before you staff it.

Your experts write the procedure. Engineering encodes it with escalation rules. If the playbook only exists in one person's head, stop and write it. An agent cannot invent a process you refuse to document.

Look up, decide, act, confirm — or it is still a chat

Four steps. Skip one and you have a demo.

Look up: the agent reads the systems you already trust, with the same permissions as the user or a narrower service role. A shared bot identity that can see every file is a leak.

Decide: the playbook is in plain language, reviewable by ops, not buried in a prompt only the vendor can edit. Exceptions escalate. "Use your best judgment" is not a playbook.

Act: the write is a real API call — ticket, refund, field update — not a suggestion the human retypes. Sensitive acts wait.

Confirm: the result is logged, attributable, and reversible. Someone can answer what it did at 14:12 without a vendor favor.

If any of those four is missing, keep calling it a copilot. Words matter when you set expectations with a support lead.

Three layers keep it from making a costly write

You will not get to zero mistakes. You can get to mistakes you can see and undo.

Shadow mode: the agent runs alongside humans on real traffic and does not act alone. Compare outcomes to the human baseline before you flip the write. If you cannot measure resolution, you cannot go live.

Human-in-the-loop: sensitive actions require an approval. The UI shows the proposed change, not a green button that says "trust me." Instant handoff to a person includes the context the agent already gathered. Teams keep the hard cases. The agent takes the routine volume.

Audit and eval: every action is logged. Every agent ships with a test suite so you know the resolution rate before customers do. Weekly tuning after go-live is part of the system, not a surprise retainer.

What "good" looks like on the product page is directional: a large share of routine requests closed without a human touch, coverage without adding headcount, production inside a quarter when the playbook is real. Those are targets, not a customer result we invented. If a vendor quotes 80 percent without a shadow period, they are selling a slide.

Build it on the systems you already have

Do not rip and replace the ticket tool to get an agent. Integrate. The agent is custom software in your environment, same as any other custom AI slice: your repos, your cloud, your identity.

That means:

• Playbooks your ops team can edit without a deploy if the rule is operational, and a deploy if the rule is a tool permission.
• The same data-class rules as the rest of governance. Restricted data does not go to a personal chatbot "just to draft the reply."
• Cost and rate limits so a retry loop is a page, not a month-end invoice.
• A one-click path to a person. Agents that trap users in a loop get turned off.

Agents do not replace the team. They absorb repetitive volume and hand humans the rest. If the pitch is headcount elimination with no playbook, keep walking.

Go live only after the baseline moves

The sequence is the same every time:

• Pick one workflow with measurable cost.
• Design the playbook with the people who do the work today.
• Encode guardrails and escalation.
• Shadow on real traffic until outcomes match or beat the baseline.
• Go live with a dashboard and a weekly tune.
• Kill or restrict if the measured share misses the assumption.

Under 90 days is a typical window when the workflow is already written and the systems have APIs. It is not a law. A messy source of record will eat the calendar. That is a data problem, not an agent problem.

If the first workflow is still a chat box, you have not started. If you have a playbook, a system of record, and a number, the next step is a scoped path to a shadow agent. See AI agents.