Agents are the easy part. The operation is the product.

Getting an AI agent to do a good job on one task is now the easy part. Models are capable, and tools like MCP make it simple to give an agent access to real systems.

The hard part is operational. When some of the work is done by people and some by agents, how does the business actually run? Who knows what work exists, who is doing it, when it runs, and what happens when it fails?

Stop thinking in chats

A chat window is a demo. Nobody can see what the agent is working on, nothing tracks whether it finished, and the output disappears into a transcript.

In production, I treat every agent run as a unit of work: a record in your domain application with an input, an output, an owner, and a status.

• Queued when the work is created
• Running when an agent picks it up
• In review when a person needs to approve it
• Done when the result is stored and visible
• Failed with the error captured, then retried or escalated to a person

Now the agent is part of the product. You can show progress in a portal, report on throughput, and see failures instead of guessing.

One queue for people and agents

Once work is a record, people and agents can share the same queue. An agent researches and drafts, a strategist approves, and the client sees the result. Each step goes to whoever does it best, and the domain app stays the single source of truth for all of it.

This is also how you adopt agents safely. Start with a person approving every result. As trust grows, move steps to fully automatic without changing the workflow.

Agents publish, applications own

The last piece is keeping agents decoupled from your core system. Agents should not write directly to your database.

Here’s an example. I built a website research agent that crawls a site and produces a structured report. When it finishes:

1. The agent publishes the report as an event to SNS.
2. SQS delivers it to the domain application.
3. The domain app validates it, stores it, and surfaces it in the client portal.

The agent does one job. The application owns the data. Adding something new later, such as an alert or an analytics pipeline, means subscribing another queue. The agent never changes.

What this buys you

• Visibility: every piece of work has a status, an owner, and a history.
• Safety: failures are a state, not a mystery, and people are in the loop where it matters.
• Flexibility: agents and consumers can be added or replaced independently.

If you are trying to get agents out of a chat window and into how your business actually runs, that is the work I do.