Enterprise AI Breaks in the Last Kilometre

An enterprise AI demonstration has generous conditions.

The document is available. The user knows what to ask. The model receives clean context. The tool works. The answer can be judged in isolation. If something goes wrong, the person running the demonstration corrects it.

Production removes those conditions.

The source changes. Access differs by user. The request arrives without context. The action crosses a permission boundary. An approval is late. A provider fails. A result needs to be explained. The person who configured the system is not present.

This is the last kilometre of enterprise AI.

It is the distance between a capable response and an operated workflow.

BAMS project workflow. All displayed data is simulated.

The Model Can Pass While the Deployment Fails

Consider a procurement review.

A model can extract payment terms, compare liability clauses, and draft a summary. That tells us the reasoning task is feasible.

It does not tell us whether the deployment works.

The production workflow also needs to know which contract version is final, whether the requester may see pricing, when legal approval is mandatory, where the risk note belongs, which action the agent may take, who owns an exception, and what record procurement needs later.

A strong answer delivered to the wrong person from the wrong document is not useful automation.

A correct recommendation turned into an unauthorized action is an incident.

The last kilometre is not a marginal implementation detail. It is where the organization's rules meet the model's capability.

Seven Breakpoints in the Last Kilometre

We see seven recurring breakpoints when AI moves from demonstration to operations.

1. No durable work object

The interaction lives in a chat history. There is no case, project, request, owner, state, or acceptance condition.

The team can see that the model produced something. It cannot see whether the work is complete.

2. Context without authority

Retrieval is tuned for relevance but not for access. The system finds a useful paragraph and forgets to ask whether this identity may use it for this task.

Enterprise context requires both relevance and permission.

3. Vague agent scope

The agent is told to "handle procurement" or "support finance." That is a role description, not an enforceable permission set.

Software needs named tools, actions, budgets, routes, and escalation conditions.

4. Approval added after the workflow

The initial design assumes autonomy. Approval appears later as a button placed in front of the final action.

By then, the system may have created drafts, changed records, called external tools, or exposed context without recording the decisions that led there.

Approval needs to be designed into the state model.

5. Evidence reduced to logs

Technical logs can help diagnose a failure. They rarely explain a business decision.

An operator needs to connect the request, source, recommendation, policy, approver, action, and result. That is workflow evidence.

6. Exceptions assigned to nobody

The happy path has an owner. Provider failure, ambiguous data, denied access, and rejected approval do not.

The result is a queue that requires the implementation team to interpret it.

7. No operational handover

The client receives the running workflow but not the operating knowledge. Route changes, access updates, recovery, evidence export, and connector failures remain supplier tasks.

The system is deployed. The capability has not been transferred.

What We Put in the Workflow

BAMS treats the last kilometre as product work.

The current reference implementation represents projects, milestones, work journals, owners, risks, approvals, agent identities, memory, provider routes, budgets, governance state, and audit activity as operator surfaces.

Those surfaces allow us to map a workflow into explicit objects.

For a bounded review process, the mapping can look like this:

1. A project or case records the business objective and owner.
2. A task records the specific request and acceptance condition.
3. An agent identity receives access to the permitted sources and tools.
4. Governed memory supplies approved context under access rules.
5. Model routing applies the permitted provider and budget policy.
6. The agent creates a recommendation rather than an external action.
7. An approval request carries the decision context to the named owner.
8. The approved action is recorded against the work object.
9. Exceptions enter a visible state with an accountable operator.
10. The journal retains the operational history required for handover.

This is less dramatic than a general-purpose autonomous agent.

It is also easier to operate, test, and own.

Start With the Acceptance Condition

Teams often begin the last-kilometre design by listing integrations. We begin with the acceptance condition.

For example:

"For every new supplier agreement in the agreed repository, produce a clause summary and risk recommendation, route high-risk clauses to legal, record the approval decision, and preserve the evidence required by procurement. Do not sign, send, or amend a contract."

That statement defines useful boundaries.

It names the source, output, escalation, record, and prohibited actions. It gives the team something it can test.

From there, the design questions become concrete:

• What counts as a new agreement?
• Which repository state is authoritative?
• Which users and agents may access each class of agreement?
• Which clauses trigger legal approval?
• Which model routes may receive the text?
• What evidence must be retained?
• What happens when extraction confidence is low?
• Who owns a rejected recommendation?
• How is the workflow paused?
• What must the client operate without BlackUnicorn?

The answers become configuration, policy, runbooks, and tests.

The FDE Is Part of the Product Boundary

The last kilometre cannot be completed from a generic configuration form. It requires access to the organization's real workflow, language, permissions, exceptions, and operating constraints.

This is why the Forward Deployed Engineer comes with BAMS.

The FDE works with the client to map one workflow into BAMS, verify sources and access, define approval and failure states, connect named integrations, build the acceptance test, and train the operators.

The objective is not to make BlackUnicorn indispensable.

The engagement should produce a client-owned operating packet:

• architecture and data-flow record
• identity and access map
• model and provider routing policy
• approval matrix
• connector inventory and health procedure
• runbooks for pause, recovery, and export
• acceptance results and known limitations
• ownership map for routine operations
• exit and handover checklist

If routine changes still require the FDE after handover, the engagement has left unfinished work.

A Practical Last-Kilometre Review

Before approving an enterprise AI workflow, ask the operator to demonstrate the following:

1. Open the durable work record.
2. Show the accountable human owner.
3. Show the agent identity and its permitted tools.
4. Show which context sources it can and cannot retrieve.
5. Show the active model route and fallback.
6. Trigger an approval boundary.
7. Reject the approval and show the resulting state.
8. Disable a provider or connector and show the failure path.
9. Pause the agent.
10. Reconstruct one completed decision from evidence.
11. Export the required record.
12. Hand the procedure to a client operator.

This review tests the workflow as an operating system, not as a prompt.

Where the Product Boundary Stands

BAMS is a working internal reference implementation being productized as a commercial beta appliance for client-controlled deployment.

The reference implementation contains the main control surfaces discussed here. Repeatable customer packaging, workspace isolation, connector hardening, and buyer evidence exports remain productization work.

We will only claim a connector that has been named, configured, and tested for the deployment. We will only claim an outcome when an approved case study supports it.

That boundary is part of the last kilometre too. A supplier should be able to distinguish what is running, what is being delivered, and what still needs to be proven.

The Last Kilometre Is the Product

Model capability is necessary. It is not sufficient.

Enterprise value appears when the right software identity uses the right context, under the right authority, inside a workflow that an operator can inspect, stop, recover, and own.

That is why we do not treat deployment as the handoff after the product sale.

For BAMS, the last kilometre is part of the product boundary. The FDE comes with it. The workflow is not accepted until the client can operate the result with documented controls and without permanent dependence on us.

The demonstration proves that the task may be possible.

The last kilometre proves that the organization can use it.

What to Put in the Workflow Specification

A compact specification gives the product team, FDE, risk owner, and operator a common object to review.

It should include:

Trigger

State what creates new work. A document arriving in a named repository is a trigger. "When procurement needs help" is not precise enough to automate or audit.

Inputs

List the authoritative sources and required fields. Define what the workflow does when an input is missing, duplicated, stale, or in conflict.

Identity

Name the software identity, accountable human owner, data scope, tools, model routes, budgets, and prohibited actions.

State

Define the states that matter to operators: new, ready, waiting for context, waiting for approval, rejected, failed, complete, or paused. Each state should have an owner and a permitted next action.

Decision

Separate the model's analysis, the agent's recommendation, and the organization's authorized decision. Record the policy or threshold that routes work between them.

Output

Define where the completed work belongs and what makes it acceptable. A fluent response is not an acceptance definition.

Evidence

Name the source, route, tool, approval, and result records required to reconstruct the work.

Failure

Define what stops, what remains queued, who is notified, and which recovery action is permitted when a source, provider, connector, or approval path fails.

Exit

State how the workflow is paused, exported, transferred, and operated if a provider or supplier relationship ends.

The Operator Review Is Different From the Model Evaluation

Model evaluation asks whether the model can produce an acceptable result for the test set.

Operator review asks whether the complete path can be run safely and repeatedly.

Both are required.

The operator should watch a normal case enter the queue, inspect the agent's scope, see the source and route, resolve an approval, handle an exception, pause work, and reconstruct the record.

The review also needs a person who did not build the implementation. If only the FDE can navigate the procedure, the workflow has not passed handover.

This is where the last kilometre becomes measurable. It is not a feeling that the deployment fits. It is a set of actions that named operators can complete against known states.

The work may reveal that a model needs improvement. It may also reveal that the organization has no owner for an exception or no authoritative source for a decision.

That is useful evidence. The deployment is showing where the operating system needs a decision rather than hiding the gap behind a plausible response.

Keep the First Workflow Boring Enough to Operate

There is a temptation to make the first enterprise AI workflow demonstrate broad autonomy.

That increases the number of sources, tools, decisions, and exceptions before the organization has established its operating pattern.

A narrower workflow can still be technically serious. It can retrieve governed context, route across local and hosted models, use an external tool, request approval, record evidence, handle a provider failure, and pass through a client handover.

The difference is that each action has a defined purpose and owner.

This produces better product evidence too. The team learns which controls operators actually use, which states are unclear, which evidence is missing, and which configuration needs to become repeatable.

The next workflow can then reuse an accepted identity pattern, route policy, approval model, connector procedure, and handover method.

The last kilometre compounds when it is documented as product and operating knowledge. It becomes expensive when every deployment begins as a custom conversation.

BAMS is being productized around this principle: keep the client workflow specific, return repeatable capability to the appliance, and leave client policy under the client's authority.

<!-- Editorial evidence: E02 in series/bams-no-strings-attached/EVIDENCE-LEDGER.md -->