The first AI-native workflow worth building is usually a narrow, repeated queue where people already spend their time collecting information and deciding what happens next. Pick work with a visible owner, a bounded set of systems, and an outcome you can measure. Leave the high-impact decisions and the murky exceptions with people until you have evidence about how the workflow actually behaves.
That is a smaller ambition than a company-wide assistant. It is also the difference between a demo that impresses a room and a system people still use six months later. The strongest first workflow gives the agent enough context to do real work while keeping its authority small enough that a bad output is cheap to catch and reverse.
Start with a queue that people complain about
Look for a queue where work waits because someone has to move information between systems, compare a record against a policy, or decide what needs attention next. Good candidates show up in ordinary operating language:
- "We have to read every request before we can route it."
- "The data is in three places, so someone builds the same brief every week."
- "We only find the missing document after the handoff has already stalled."
The complaint by itself is not enough. A queue becomes a candidate when you can state the trigger, the inputs, the expected output, and the owner in a few sentences. Take a support team handling an account-change request. Someone pulls the account history from approved systems, writes a structured case summary, and sends anything ambiguous to the account owner. Every step there has an edge you can point at.
Sennu has delivered more than 25 AI projects, and the starting point is almost never a request to add AI. It is usually one specific delay, either between two people or between a person and a system. The first job is making that delay visible enough to argue about.
Score the work before you build it
Run each candidate through a short scorecard. It does not need to be precise. It needs to get the tradeoffs onto the table before anyone commits engineering time.
1. Is there enough repetition?
Count how often the work happens and what it costs today. Something that comes up twice a year can still matter to the business, but it is a bad place to learn how an agent behaves. Frequent work gives you enough cases to test against and enough history to compare with the old process.
2. Can you name the source of truth?
Write down the folders, records, and fields the agent may use. Then write down what it must never touch. If a contract or an internal system sits outside the task, keep it outside the agent's permission scope too.
Build that list into the agent's permission scope. OWASP's guidance on excessive agency recommends running downstream actions in the requesting user's context, granting the minimum privileges the task needs, and requiring approval before high-impact actions. The OWASP write-up on excessive agency explains the security reasoning.
3. Can the output help without being final?
Early workflows work best when the agent produces something a person can inspect: a categorized ticket, a filled-in intake checklist, a reconciled record with its sources attached, a suggested route. The reviewer accepts it, fixes it, or throws it out.
Keep the expensive-to-undo actions out of the first release. Changing a contract, granting access, issuing a payment, deciding someone's credit or employment: those may be automatable later, but each one needs its own risk, policy, and testing decision first.
4. Are exceptions visible?
Every workflow has an unhappy path. An input goes missing, two systems disagree, a scan is unreadable, a customer asks for something policy does not cover. If nobody can say where those cases should land, the workflow is not ready to act on its own.
Write the exception policy before implementation. Say which conditions stop processing outright, which ones produce a low-confidence result, and who receives the review item. Keep the source record and the reason it stopped attached to the case. A reviewer should not have to rebuild the agent's path out of logs.
5. Can you measure the operating result?
Pick the measure before you build. It might be time from intake to review-ready case, analyst minutes per request, the share of outputs accepted without edits, routing accuracy, or the age of the oldest item in the queue. Pair the headline number with a safety measure such as override rate or incorrect-action rate.
Measurement is not a launch task. Build an evaluation set out of real historical cases before the first release, then run it again after every meaningful change to prompts, tools, or data access, and keep watching those numbers once the workflow is live. Something that scored well on last quarter's cases can drift when a document template changes or someone reorganizes a source system. If nobody owns that recheck, you will hear about the regression from a customer.
How much system you need is a measurement question too. Anthropic's engineering guidance on building effective agents recommends adding complexity only when it demonstrably improves outcomes. In practice, one well-scoped step with a solid review queue usually beats a multi-agent design that nobody can debug when it breaks.
Turn the scorecard into a small production slice
Once a candidate scores well, cut it down further. Give the first version one trigger, a limited action set, and a clear rule for when it is finished. A reasonable first implementation looks something like this:
- A new request enters an approved queue.
- The agent reads only the records that request needs.
- It produces a structured result with links back to its source material.
- A validation step checks required fields, policy conditions, and obvious conflicts.
- Exceptions and high-impact actions go to a human reviewer.
- The system records the output, the reviewer's edits, and the final disposition.
The agent's authority stops at the boundary you set. It should not drift from preparing a case to changing customer data because a tool happens to be connected. Keep tool permissions separate from model instructions, and make the agent pass the same authorization checks the application already enforces.
Run it beside the current process
Do not judge the first version on how well it writes. Run it in parallel with the existing workflow for long enough to see real variety, including the messy cases from past quarters: the missing documents, the conflicting records, the requests policy does not cover. Look at where the agent was right, where it was thin, and where it should have stopped and kept going instead.
Then move in order. Start with preparation and review. Get the audit record and the exception queue dependable. Then add actions one at a time, each with its own boundary, as the operating data supports it.
What you end up with is narrow, and that is the point. People spend less time assembling information and chasing routine handoffs, and they keep the judgment calls, the policy decisions, and the exception handling that make the work safe. That is a smaller promise than most AI pilots make, and a much easier one to keep once the demo is over.