Enterprise AI: tasks, artifacts, and delivery

An enterprise request often arrives as a few spoken requirements, several product images, an old spreadsheet, and one sentence: “Can you give me something we can actually execute?”

A model can quickly organize that material into a convincing response. The work has barely begun. Someone still has to decide whether a specification in an image is trustworthy, who supplies a missing field, which pricing rules apply, which version may be sent to the customer, and who approves the final file.

I have learned to work backward from the deliverable. First identify the object that must be inspected, approved, sent, manufactured, or audited. Then decide which part belongs to conversation, the model, deterministic rules, and human judgment.

The resulting enterprise AI may look less like a chatbot. It looks much more like a system a company can use repeatedly.

A task is larger than a conversation

A customer request often begins as an untidy mixture of language, files, images, assumptions, and missing information. Conversation is useful for resolving that ambiguity, but it is not a sufficient container for the work.

A task needs durable facts:

• what the user is trying to accomplish;
• which inputs have been confirmed;
• which rules and constraints apply;
• what has already been executed;
• which result is current;
• who approved the next consequential action.

If those facts only exist inside a transcript, the product has delegated its state model to prose. It may feel flexible, but it becomes difficult to resume, audit, or operate reliably.

This is why I prefer a task-led product with conversation inside it, rather than a chat-led product with tasks hidden behind messages.

A quoting task exposes the distinction well. The model can extract specifications, find missing inputs, and explain a draft. Deterministic calculation applies prices and business rules. A reviewer resolves exceptions. The final quote is delivered as an explicit version. Conversation makes the information complete, but downstream execution depends on the confirmed artifact—not whichever message happens to look most complete.

The model should translate the boundary

Language models are exceptionally useful at the uncertain edge of a system. They can interpret a loosely described goal, read unfamiliar material, identify missing inputs, and produce a structured draft.

That does not make the model the source of truth.

Prices, eligibility, risk rules, approval requirements, side effects, and production files should come from deterministic systems wherever the business already has a definition for them. The model can explain those systems and help users interact with them; it should not quietly replace them with plausible text.

A useful division of responsibility is:

• the model interprets and proposes;
• the product confirms and records;
• rules and services execute;
• people approve decisions whose consequences matter.

This is less magical than asking one model to do everything. It is also far easier to trust.

The deliverable carries the value

The most important output is usually not the assistant message. It is the artifact produced by the work: a quote, a report, a brief, a plan, a reviewed dataset, a production file, or a decision record.

Artifacts have properties that messages do not naturally have. They can be versioned, compared, approved, rejected, downloaded, handed to another system, and traced back to the evidence and rules that created them.

The conversation still matters, but it becomes the place where intent is negotiated and decisions are explained. The artifact becomes the place where value accumulates.

This distinction also improves the interface. Instead of asking users to search a long timeline for the latest answer, the product can show the current result, its status, its evidence, and the next decision required.

Human review is part of the architecture

Human-in-the-loop is often treated as a temporary concession: a manual step to remove after the model becomes better.

In enterprise work, that is the wrong framing. Review is how responsibility becomes explicit.

A useful system makes clear:

• which fields came from the user, a source document, a rule, or a model;
• which assumptions remain uncertain;
• which action will create an external effect;
• who confirmed the decision;
• what changed after rejection or correction.

The goal is not to interrupt people more often. It is to place human judgment exactly where authority, ambiguity, and consequence meet.

Reuse follows delivery, not abstraction

There is a strong temptation to build a general platform first: a universal expert builder, a workflow engine, a marketplace of agents. But enterprise differences are not noise to be abstracted away. They are often the business itself.

The reusable layer should emerge from repeated delivery. Identity, task state, audit, artifacts, model access, and execution infrastructure may generalize. Pricing rules, production constraints, approval language, templates, and exception handling usually belong to a specific solution.

The test of a platform is therefore not how many configurations it exposes. It is whether the next real solution can be delivered faster without weakening the business boundary.

The business proof is outside the model

An enterprise does not ultimately buy an Agent. It buys a shorter turnaround time, fewer mistakes, faster onboarding, more consistent decisions, or a process that can finally be inspected.

That is also the most honest evaluation of the product.

The hard questions are not how many tools the system can call or how impressive the demo looks. They are whether people return to complete the same task, whether the artifact survives real review, whether exceptions become easier to handle, and whether the next deployment costs less than the first.

Enterprise AI becomes durable when intelligence is no longer the final output. It becomes one component in a system that produces accountable work.