AI Agents in the Enterprise: Where to Start

When a workflow needs an agent

Suppose a support request asks why an invoice changed. A fixed workflow can fetch the invoice, compare it with the previous one, and pass both to a model for an explanation. That may be enough.

An agent becomes useful when the next step depends on what it finds. It might need to inspect a plan change, find an adjustment, or ask the customer which account they mean. The model chooses among those steps and uses the results to continue.

Anthropic’s guide to building agents (opens in a new tab) makes a useful distinction between predefined workflows and systems where the model directs its own tool use. It also recommends beginning with the simplest approach that works. I agree with that starting point: every extra decision creates another behavior to test.

If the path is predictable, write the workflow. If choosing the path is the difficult part, try an agent and compare it against that simpler baseline.

A tool call is an application operation

A useful agent loop takes a request, gathers relevant context, proposes a tool call, and observes the result. The application decides whether that call is allowed. This separation matters when a tool can change data or contact another person.

Give tools narrow responsibilities. A support agent can call get_invoice and list_adjustments without receiving a general-purpose database credential. Scope access to the authenticated user’s account on the server. An account ID supplied by the model is input to validate, not proof of authorization.

Available without additional approval:
  Read invoices for the authenticated account
  Read the applicable billing policy
  Draft an explanation with invoice references

Requires approval:
  Send the explanation to the customer
  Apply a credit through the billing service

Never delegated to the model:
  Decide which accounts the current user may access

Set a maximum number of steps and an execution deadline. When the agent cannot resolve the request within them, return the evidence gathered so far and the missing information. A partial answer with a clear limitation is easier to act on than a confident guess.

Memory and multiple agents

Store information that has an owner

Working state includes the current request, retrieved records, and completed steps. Longer-lived memory might hold a user preference or a previously reviewed procedure. These need different retention and access rules.

A remembered preference should record who supplied it and whether it still applies. A billing rule belongs in a maintained policy source. Copying it into an agent’s memory creates another version that can go stale. For factual answers, fetch the current record and keep its identifier with the result.

Split work only where the split helps

Separate agents can investigate independent questions in parallel. For the invoice example, one might compare line items while another finds the applicable policy. Their outputs should be bounded: evidence, source references, and unresolved questions.

This also adds coordination cost. Two agents can duplicate work, misunderstand a handoff, or agree on the same wrong assumption. Assigning a second model to review the first does not make the answer independently verified. Check important claims against records or deterministic rules.

The same rule applies to multimodal input. Reading a screenshot may help locate a problem, but extracted amounts and account details should be checked against the underlying record before acting.

Choose a useful first task

Look for work that requires gathering scattered information but has a result someone can verify. Three plausible starting points are:

• Support investigation: collect relevant account events and draft an explanation, with links to the records.
• Operations triage: inspect alerts, recent releases, and runbooks; suggest the next diagnostic step.
• Internal analytics: find the correct dataset, propose a query, and explain the filters used in the result.

These are design examples, not claims about a particular company’s deployment. Each can begin with read-only access. Write access can follow if the task needs it and the evaluation supports it.

Avoid a first project whose success depends on broad discretion and unclear ownership. “Investigate this alert” is a testable scope. “Manage our infrastructure” leaves too many decisions undefined.

Plan for failure

Consider a credit operation that times out. The timeout does not tell you whether the billing service applied the credit. Retrying blindly can apply it twice. Use the service’s idempotency mechanism where available and reconcile the operation’s status before retrying.

Retrieved text brings a different problem. A ticket, document, or web page may contain instructions aimed at the agent. Treat those contents as task data. Enforce tool permissions outside the model so a sentence in a document cannot grant additional access.

Logs should let an operator reconstruct what happened: the request, selected tools, relevant inputs, returned errors, and final outcome. Keep credentials and unnecessary personal data out of those logs. Record observable actions and evidence; a generated explanation of the model’s reasoning is not an audit trail.

Evaluate before expanding

Build a small set of representative tasks with expected outcomes. Include ambiguous requests, missing records, denied permissions, stale documents, and failed tool calls. A test set containing only successful examples will miss the behavior operators need most.

Evaluate the outcome and the actions separately. An invoice explanation can be factually correct while the agent accessed an unrelated account to produce it. A draft can be useful even when the agent correctly stops before an action it lacks permission to take.

• Did it complete the task or identify the missing information?
• Do the cited records support its explanation?
• Did it stay within the allowed data and operations?
• How much review, time, and cost did the result require?

Compare those results with the existing process. If reviewers spend longer checking the output than they would doing the task, a high completion rate tells only part of the story. Re-run the same cases when the model, prompts, tools, or retrieval sources change.

Choose tools you can inspect

A framework is useful if it makes state, tool calls, failures, and recovery easier to understand. Before committing to one, trace a failed request end to end. Check how it stores state, resumes work, exposes intermediate results, and lets you stop execution.

For a first deployment, I would keep the scope small enough to explain on one page: the task, the data it can read, the actions it can take, the point where a person intervenes, and the evidence needed to expand access. That gives the team something concrete to build and review.