MELLORCATalk to Mellorca
Discovery›AI, Automation & Agent Operations
AI, Automation & Agent Operations · Discovery

Why AI Agents Can Answer Questions but Cannot Complete Work Across Business Systems

An agent may understand the request perfectly yet still stop at advice because the business has not connected it safely to the systems, actions and controls required to finish the job.

Mellorca Discovery·AI, Automation & Agent Operations·3 September 2026

The problem in plain language

The organisation launches an AI assistant that can retrieve policy, explain a customer case or recommend a next step. But when the user asks it to update the CRM, create a ticket, change a record or complete a multi-step process, the agent hands the work back to a person.

Users notice quickly. The assistant is helpful for reading and summarising, but the work they are measured on still happens in the same screens, with the same copying between systems. The agent becomes a faster way to find out what to do, not a way to get it done.

What the buyer is actually trying to solve

Searches such as "AI agent integrate with business systems", "agent actions across applications", "AI agent workflow automation" and "connect AI agents to APIs" point to the same requirement: move from conversational assistance to controlled execution.

The buyer is rarely asking for a cleverer model. They are asking why the pilot that impressed in a demonstration has not changed cycle time, handling effort or backlog in the live operation.

Evidence and system mechanism

Current Microsoft Copilot Studio documentation distinguishes knowledge from tools and exposes connectors, MCP servers and workflows as mechanisms through which agents can read, write and execute actions in external systems. It recommends workflows for multi-step, automated, deterministic processes. Microsoft's integration planning guidance documents connectors, HTTP requests and agent flows, and notes practical constraints: integrations are only as fast as the endpoints they connect to, third-party connectors may prompt users for credentials, and the developer must design an error-handling pattern so the agent knows how to handle exceptions. It also suggests planning each integration by connected system, calling component, method and expected volume.

The NIST Generative AI Profile (NIST AI 600-1) treats AI deployment as a lifecycle risk-management problem rather than a model-only problem, covering design, development, deployment and evaluation.

The mechanism is therefore broader than prompting. Completion requires authenticated tools, reliable data contracts, permissions, deterministic workflow steps, exception handling, observability and human-control boundaries.

How the gap appears in practice

The following is an illustrative example rather than a client case. A service agent is grounded on the knowledge base and the customer history. A customer asks to change a delivery address on an open order. The agent correctly explains the policy and confirms the change is allowed. It then has no tool to update the order system, no way to check whether the shipment has already been released to the warehouse and no defined route for the case where it has. It tells the customer that a colleague will follow up, and an employee repeats the lookup, the policy check and the update by hand.

Each missing piece is ordinary integration work: an authenticated write action, a status check against the authoritative record, a rule for the exception and a log of what was done. None of it is solved by improving the model's answer.

Problem owner and why now

Automation or AI platform leaders usually own the technical capability, while the COO often owns whether the process actually improves. The issue becomes urgent when an AI mandate moves from experimentation into operational productivity targets, when licence or consumption costs need to be justified, or when users start working around the agent because it cannot finish the job.

Warning signs

  • Success is reported as conversations or user satisfaction rather than completed transactions.
  • The agent's final step is usually "please contact" or "a colleague will".
  • Pilots run on read-only access because nobody has agreed write permissions.
  • Integration is described as "phase two" with no owner or date.
  • Nobody can say what the agent did in a given case without reading the transcript.

Economic consequence

If the agent can only advise, employees still perform the system work. That can preserve handoff delay, duplicate effort and supervision overhead while adding another technology layer. The business case depends on completed outcomes, not conversations.

There is also a cost to over-correcting. Granting broad write access to make the demonstration work can create a different problem: actions that are hard to explain, reverse or audit. The value comes from narrow, reliable execution, not from maximum reach.

Root cause

Common causes include missing integrations, fragmented authoritative data, excessive or insufficient permissions, unclear process boundaries, no durable transaction state, and no defined path for exceptions or human approval.

Underneath these is a sequencing error. Many programmes start from the model and look for work it can do, rather than starting from a workflow and asking which steps an agent can safely own. The first approach produces assistants; the second produces completed work. Related failure modes are examined in agent conversations not connected to durable business records and agent permissions broader than the task requires.

Practical intervention

  1. Select one bounded workflow with a measurable outcome.
  2. Map the systems and records the agent must read or change.
  3. Define tool contracts, permissions and approval boundaries.
  4. Use deterministic workflows for predictable multi-step execution where appropriate.
  5. Persist business state outside the conversation.
  6. Design error handling for each tool so failures are visible and recoverable.
  7. Monitor actions, failures and exceptions.
  8. Evaluate whether the workflow is completed correctly, not merely whether the model responds well.

Trade-offs

Deterministic workflows are predictable and auditable but rigid; letting the model choose its own sequence of tools is flexible but harder to test. A sensible pattern is to let the agent interpret the request and choose among a small set of well-defined actions, each of which runs as a controlled workflow. Human approval adds safety and delay, so place it on actions that are costly or hard to reverse rather than on every step.

A useful first measure is the completion rate for one workflow: of the requests the agent starts, how many reach the correct end state in the authoritative system without a person redoing any step? Track it alongside the exception rate and the time people spend on the cases the agent hands back. Those three numbers show whether the agent is removing work or relocating it.

Diagnostic questions

  • Which business actions can the agent perform today?
  • Which actions still require copy-and-paste by a person?
  • Where is authoritative state stored?
  • What happens when a tool call fails?
  • Which actions require human approval?
  • What share of started requests finish without a person repeating the work?

What good looks like

The agent is one controlled actor inside a defined workflow. It has only the tools and permissions it needs, writes to durable business records, exposes exceptions and hands off with context when human judgement is required, as described in why AI agent handoffs need enough business context. Performance is measured by completed outcomes and the effort removed from people, and each new capability is added because a workflow needs it.

Where Mellorca fits

Mellorca can map the workflow, define system and data contracts, implement integrations and agent tools, establish human-control points and operate monitoring around the resulting automation.

Commercial next step

Discovery article → agent-readiness diagnostic → workflow and integration map → bounded pilot → production implementation → managed monitoring.

Sources and further reading

Related Mellorca reading

Method noteThe sources establish current agent integration and risk-management mechanisms. They do not prove prevalence or ROI. Quantify value from the specific workflow's completion rate, human effort, exceptions and business outcomes.