Use cases are not enough to make agents work

Most AI conference decks have a slide called "use cases." Meeting summarizer. Support copilot. Sales-research bot. Contract-review assistant. Outbound personalization. These are helpful ways to start because they force the right basic questions: what problem are we solving, what data do we need, who is involved, and what value should this create?

Those questions matter. But a use case is still one slice of work.

The bigger value comes when many slices coordinate across people and process. In a company building complex physical products, one engineering problem can touch customer feedback, sales commitments, quality escapes, manufacturing constraints, engineering change orders, R&D decisions, IT systems, and finance tradeoffs. If each use case becomes its own isolated agent, you have more point solutions. You have not changed how the business works.

That is where many agent rollouts stall. Agents can make silos worse if they are added one task at a time without the people and process around them. Or they can help repair the coordination problem by fitting into the way the business actually runs.

That connected layer is what I mean by an operating model: who owns the work, what process it belongs to, when the agent acts, who it works with, what it escalates, and where the output goes. The point is not to stop using use cases. The point is to make sure each use case lives inside the operating model of the business.

Where use cases stop short

A use case usually assumes a narrow shape:

The agent waits to be asked.
The output is the deliverable.
The conversation is the unit.
The user provides the context.
Success means the response was useful.

That can be fine for a narrow task. The problem starts when every agent is designed this way. The agent may help in the moment, but it does not know what happened before, what should happen next, who else needs to know, or where the work should be recorded.

This is how point-solution agents show up in practice. An agent can analyze a sales call well and have no idea when a sales call happens, no responsibility to update the CRM after, no awareness that the VP should hear about the competitor mention, and no read on whether the customer success team needs the insight before the next QBR. The use case helped, but the broader job still broke.

This is not only an integration problem you solve by adding webhooks. It is a design problem. The agent was designed as a point solution, not as part of the way the business works.

Start with people and process

The reframe is simple: do not start by asking what the agent can do. Start by asking how the work happens today.

Who owns the work? What process does it belong to? What systems does it touch? Who reviews the output? Who needs to be notified? What decisions require human judgment? Where does the final artifact live?

Once you answer those questions, the agent has a place to operate. It is not just a feature waiting to be invoked. It has a role inside the process.

That is the operating model. In practical terms, it contains:

Scope of work: what the agent is responsible for, defined by the business concern it owns, not by the tool it can call. A maintenance triage agent is not just the agent that calls the work-order API. It is responsible for machine health on Lines 3 through 7.
Human owner: the person or team the agent reflects, reports to, and learns from. This is how human judgment stays in the loop. The agent acts, the expert reviews, the patterns get refined, and the agent's judgment improves. Without this, the agent's judgment freezes at the moment of deployment.
Triggers: events that cause the agent to act without waiting for a prompt. A new transcript lands in the discovery folder. A margin comes in under plan. A schedule slips past the safety buffer. Triggers turn the work from a passive chat into an active process.
Escalation paths: the named conditions where the agent stops and hands work to a human, with the context staged. Not "if confused, say I don't know," but a specific escalation to a specific person or team.
Handoffs: the people, agents, teams, and systems the work has to move between. When the maintenance triage agent sees that Line 4 may be down for three hours, it does not only log the ticket. It tells the logistics team so the 4 PM pickup can be re-routed.
Artifacts: the durable outputs the agent creates or updates: records, reports, tickets, requirements, risk registers, and decisions. Chat replies do not count.

A use case may not define any of these. It often has an input and an output, but the structure around the work is what is missing.

Why this matters in engineering

This matters most in companies building complex physical products. Engineering can look like a silo from the outside: the team designs the product, releases the drawing, and moves on. But the real engineering process is much more connected than that.

Engineering needs to understand what customers are asking for, what sales promised, what marketing is hearing, what manufacturing can actually build, what quality is seeing in the field, what R&D is testing, what IT systems support the CAD and PLM stack, and what finance needs to know about time and resource allocation.

If you add agents one use case at a time, you can make that fragmentation worse. A non-conformance agent lives in quality. An engineering-change agent lives in PLM. A customer-feedback agent lives in sales. A CAD automation agent lives with engineering. Each one may work, but the business still has to reconcile the full story by hand.

The opportunity is to make those use cases work together. A non-conformance should be able to inform design. A design change should connect to manufacturing constraints. A customer request should connect to engineering capacity and cost. That is the operating model showing up in agent design.

A worked example: discovery triage

One of our customers, a consulting firm, runs Kinaxis Maestro implementations, a planning and orchestration platform their customers roll out over twelve to twenty-four months. Every project starts with weeks of discovery meetings producing user stories, the modern requirements format these implementations standardize on. The team that maintains the user-story library spends a lot of their week reading transcripts, deciding which conversations contained requirements, drafting candidate stories, deduplicating against the existing library, and emailing the curator a clean proposal.

The narrow use case would be: summarize the meeting and extract action items. That may help, but it does not carry the work through the process.

The operating-model version is discovery triage. The agent watches the meeting folder, decides whether a transcript contains requirements, drafts candidate user stories, checks them against the existing library, flags conflicts, sends the curator a clean proposal, and waits for a decision. The work still belongs to people. The agent keeps the process moving and preserves the context.

Written as the role description we would give a new hire, the responsibilities look like this:

Watch every meeting that lands in the discovery folder. For each one, decide whether the conversation produced requirements. If yes, extract candidate quotes. If no, drop it.
For each quote that survives, draft a candidate user story in the project's standard format, with provenance attached: which meeting, which speaker, which prior decision the story builds on.
Check the candidate against the existing library. If a duplicate exists, suggest a merge. If a conflict exists with a prior decision, flag it.
Bundle the surviving candidates into a curator email, ranked by confidence, with the conflicts at the top.
Wait for the curator to accept, reject, or ask a question. Apply the answers back into the library.

Every bullet is a verb the agent owns. The whole thing reads as a role description, not a feature spec.

The implementation is the workflow we use for multi-stage agent flows: a meeting indexer dimension, a discovery classifier dimension that gates further work, a user-story ingestor dimension that drafts the candidates against the project's design decisions, all dispatched as separate work orders so each step gets a clean context window. The peer connections are the project graph itself: the ingestor knows which prior design decisions a candidate touches because the graph names them. The escalation path is the curator email; the agent stops there, by design, because the call on whether a story enters the library is the curator's.

The narrow version would have been a chat box that the team copies meeting transcripts into. It might summarize well, but the team still has to notice the meeting, carry the output into the requirements process, check for conflicts, and route the decision to the curator.

The operating-model version watches, classifies, drafts, checks, bundles, waits, and learns. It hands off when it should. It knows what it owns and what it does not. The whole loop is the job. The use case is one slice of it.

Escalation is part of the process

One piece of the operating model is worth calling out because it is where many agent designs break: escalation.

In a Toyota plant, an Andon cord gives an operator a clear way to stop the line when the work crosses a boundary. The point is not the cord itself. The point is that the boundary is part of the process. Everyone knows when to stop, who responds, and how the work restarts.

Agents need the same kind of boundary. Not "I am uncertain" based on a vague confidence score, but "this is the kind of decision I am not authorized to make." Examples: a pricing exception above the negotiated band, a user-story conflict that needs a product decision, or a maintenance fault that affects a customer's contracted ship date. The escalation hands work to a named human, in a named place, with the context staged.

The shape is straightforward: the agent stages the work, names the decision needed, lists the relevant context, and stops. Here is the prior decision. Here is the conflict. Here is what the customer was promised. The human acts. The decision flows back into the graph and updates the agent's context. Next time, the agent's judgment is calibrated by the answer.

This is operating-model machinery. A point-solution agent often has no real escalation path. It apologizes, refuses, or gives a low-confidence answer, and the work does not move forward. A process-aware agent knows when to stop and who should take over.

A practical test

Before you build or buy an agent, ask how the use case fits into the business:

What does it own? (If the answer is "it answers questions," it's a use case.)
What triggers it without a human asking? (If the answer is "nothing," it's a use case.)
Who does it talk to besides the person prompting it? (If the answer is "no one," it's a use case.)
Where does its work live when it's done? (If the answer is "in the chat history," it's a use case.)
What does it escalate, and to whom? (If the answer is "it apologizes," it's a use case.)

If the answer is unclear across those questions, the use case may still be helpful, but it is not yet an operating model. You may get a useful point solution. You should not expect it to change how the business runs.

What to do Monday morning

If you are evaluating an agent use case, do not stop at the task. Design the process around it.

Write the process description, not just the prompt. What work does this support? Who owns it? What happens before and after?
Name the scope. What business concern is the agent responsible for?
Wire the triggers. What should cause the agent to act without waiting for a prompt?
Wire the handoffs. Which people, teams, systems, and agents need to receive or review the work?
Wire the escalation path. Which decisions require a human, and where should the agent stage the context?
Wire the artifacts. What record, report, ticket, requirement, or decision should be created or updated?

When you are done, you have more than a feature list. You have a use case that knows where it lives in the business.

The question is not only, "What can this agent do?" The better question is, "What operating model does this use case need to live inside?"

This is what we're building at Make Yourself AI: agents designed around the people, process, handoffs, and judgment that make the business run.