The phrase “AI strategy” invites a company to begin at the wrong altitude.

It produces inventories of models, vendors, departments, and possibilities. It encourages a steering committee to debate platforms before anyone has named a piece of work. Months later, the organization may have licenses, policies, and a backlog of ideas—but no task that an AI system carries from beginning to end.

We prefer a smaller opening question:

What repeated job does your team stitch together by hand every week?

Not a department. Not a persona. Not “customer service.” A job with a recognizable beginning and end.

It might be preparing an account review from six scattered systems. It might be turning an approved request into a configured workspace. It might be triaging a queue, gathering missing evidence, drafting a response, and routing the exception to a human. The task should occur often enough to matter, be painful enough that people have invented workarounds, and have an outcome that someone can inspect.

That job description becomes the center of the architecture. The model is only one part of it.

A prototype answers questions. A worker owns a bounded outcome.

The first prototype usually looks promising. Connect a model to a few tools, add instructions, and watch it retrieve information or draft a useful artifact. The temptation is to keep expanding the prompt until the prototype appears to understand the whole operation.

That path works for demos because demos are curated. Real work is not.

Real requests are incomplete. Two systems disagree. Credentials expire. A customer name maps to three records. One source is fresh and another stopped synchronizing last Tuesday. A person says “okay” in a conversation, but nobody knows whether that meant “I saw it,” “continue the analysis,” or “you are authorized to make the change.”

The difference between a prototype and an AI worker is therefore not fluency. It is ownership under constraints.

A worker needs:

Once those requirements are explicit, the architecture changes.

The smallest useful architecture has a dispatcher, specialists, and a merge

A common first design is one agent with a long prompt and a large toolbox. It knows the business, writes documents, searches systems, plans actions, and checks its own work.

That design fails gradually. Every new instruction competes with the previous ones. Tools overlap. Evaluations become hard to interpret. When the agent produces a poor result, the team cannot tell whether the failure came from retrieval, routing, domain judgment, permissions, or synthesis.

The better shape is a deliberately unremarkable dispatcher.

Its job is to decide whether a request belongs to:

  1. a deterministic capability;
  2. a narrow specialist;
  3. a packaged workflow;
  4. a human decision.

Each specialist receives only the instructions, tools, and data appropriate to its role. The account-research specialist cannot send external messages. The document specialist does not need access to financial systems. The action specialist receives an approved plan, not an open-ended conversation.

This is less about imitating a team of people than about creating isolation boundaries. A specialist with one responsibility and five capabilities can be evaluated. A universal agent with fifty capabilities is mostly observed through anecdotes.

One dispatcher routes evidence to three specialist stations before their outputs converge into a single reviewed folio
Parallel specialists create speed; the controlled merge creates a useful business result.

Delegation also needs a contract. Every handoff should specify the requested output, evidence expectations, time budget, and allowed failure state. “Research this account” is weak. “Return the three material changes since the last review, cite the source and observation time, and mark gaps instead of inferring them” is an executable assignment.

Parallel work is cheap. A useful merge is hard.

Once work is decomposed, several specialists can run at the same time. This creates impressive demonstrations: five streams finish in seconds instead of one person opening five tabs in sequence.

But concurrency is not the product.

If the system concatenates five summaries, it has simply moved the user’s tab problem into one long document. The value is in the merge:

The merge needs an opinionated output contract. For an account review, that might be a one-page brief with changes, risks, open commitments, and source-linked questions. For queue triage, it might be ranked cases with confidence, missing evidence, and the next permitted action.

This is a useful test for an AI opportunity: if nobody can describe the merged deliverable, the task is probably not yet understood well enough to automate.

Keep the worker separate from the window

Another early mistake is to treat the interface as the agent.

The team builds a chat application. The instructions, memory, tool wiring, and task state become entangled with that interface. Then someone needs the same capability in a scheduled job, a review queue, a command line, or an existing business application—and the agent must be rebuilt.

The durable asset should be the worker’s contract: its role, capabilities, policies, memory access, and work-state transitions. Interfaces should be replaceable clients.

That separation changes the investment logic. A company does not need to predict which chat surface, agent runtime, or model provider will dominate next year. It needs a portable worker definition and stable boundaries around business state.

The same bounded worker can then appear where the job demands:

The conversation is a surface. The work survives it.

A stable memory and policy core connects to four replaceable work surfaces
The worker contract is the durable asset. Chat, review queues, scheduled runs, and operator consoles are replaceable clients.

Memory is not chat history

A repeated job cannot depend on the user restating its history every time. But “save every conversation forever” is not a memory architecture.

Operational memory needs structure and lifecycle.

At minimum, distinguish:

Raw events can be compacted into useful state. Repetition can be deduplicated. Short-lived operational detail can expire. Important decisions should retain provenance and later contradictions.

The objective is not maximum recall. It is the smallest trustworthy context for the job at hand.

This also protects the business from platform churn. Models will improve, context windows will grow, and interfaces will change. The company’s accumulated operational state should not vanish when any of them do.

Put the rules where the model cannot reinterpret them

Prompts are useful for judgment. They are weak policy boundaries.

If an external message must be approved, the enforcement point should sit in front of the send capability. If a build cannot begin before design approval, the write operation should check explicit approval state. If destructive actions are forbidden, the tool layer should deny them instead of asking the model to remember a warning.

The rule is simple:

Use language to guide judgment. Use code to enforce authority.

That does not mean interrupting a human constantly. Excessive approval prompts train people to click through them. Good governance asks rarely, at meaningful transitions, and continues to enforce the state even when it does not ask again.

Autonomy should then graduate by action class. A system may earn the right to update an internal status field while still requiring approval to contact a customer. “Autonomous” is not a global switch. It is a set of permissions backed by observed reliability.

Build the evaluation before the expansion

An agent is software whose behavior depends on language and evidence. It still needs regression tests.

Test the dispatcher: does it select the right specialist and respect the requested audience? Test the policy: does a draft remain a draft? Test the real path: can a newly created user complete the workflow, not merely a seeded test account? Test the outcome: does the final state exist in the authoritative system?

Every production failure should become a permanent check. Prompts drift. Models change. A pinned assertion preserves what the organization paid to learn.

The first engagement is an apprenticeship

The safest way to introduce an AI worker is to let it learn one job under supervision.

During that apprenticeship, the system should expose its evidence, produce drafts, record exceptions, and show where human judgment remains essential. The team learns which parts are stable enough to automate and which parts were never actually standardized.

The output is not merely an agent. It is a better description of the operation:

Only then should the company add another job.

An AI strategy can emerge from several working apprenticeships. It rarely works in the opposite direction.

Pyranthus starts with one task your team repeats every week. We map it, rank its payoff and risk, and ship the first working system with human checks and a handoff runbook. Bring us a workflow.