How to Start with AI Agents Without Starting with an Agent

A 90-day fieldbook for moving one business workflow from evidence to a production decision

Altivate | Published 28 June 2026 | Updated 26 July 2026

1. Choose work before choosing autonomy

An organisation does not get started with AI agents by selecting a platform. It gets started by finding work where three conditions meet:

1. the outcome matters;
2. the current path contains enough ambiguity to justify model reasoning;
3. the action can be bounded, observed and stopped.

OpenAI’s use-case guidance recommends sourcing specific work opportunities and comparing impact with effort. Anthropic makes a useful architecture distinction: workflows follow predefined code paths, while agents direct their own process and tool use. Both are vendor guidance. Together they support a practical rule:

A retrieval answer may solve a policy question. A model with one tool may solve a live-status question. A deterministic workflow may solve a known sequence. Use an agent when the system must choose among paths based on evidence it discovers during the task.

This is why a good first use case is neither trivial nor enterprise-wide. It has enough uncertainty to learn from, but a consequence small enough to control.

Use the architecture selector before this fieldbook. If the selected design can act, apply the action-level readiness test.

2. Write a one-page pilot charter

Before a prototype, complete this charter in plain language:

If the team cannot complete the owner, outcome or baseline fields, an agent prototype will create a demo and postpone the real work.

OpenAI’s guide describes agents as a model, tools and instructions. In an enterprise pilot, add four equally important components: identity, evaluation, execution control and an operator.

3. Days 1-15: map the real work

Observe the queue instead of relying on the written procedure.

Collect a bounded sample of completed, failed, escalated and abandoned cases. For each case, record:

• what started the work;
• which source or system supplied each fact;
• which decisions followed rules and which required judgment;
• where people searched outside the formal process;
• which exceptions changed the path;
• what state proved the outcome;
• which actions had financial, legal, safety, service or employment consequences.

Then break the job into actions. “Resolve a service case” might become:

1. identify the customer and product;
2. retrieve the applicable entitlement and policy;
3. inspect current service state;
4. classify the issue;
5. draft a resolution;
6. route or execute the permitted action;
7. confirm the committed state.

Do not assume every action needs a model. Identity lookup and limit checking usually belong in deterministic services. Retrieval needs source governance. Drafting may use a model. Execution needs live authorisation and exact validation.

Deliverable: an action inventory, baseline and pilot charter approved by the business owner.

4. Days 16-30: build the evaluation before the agent

Create a test set from real work. Start small enough that humans can read every case, then expand as failure classes become visible.

Include:

• common successful cases;
• incomplete and contradictory records;
• stale data;
• policy exceptions;
• inaccessible sources;
• duplicate requests;
• tool timeouts and partial failures;
• untrusted content containing instructions;
• attempts to exceed the allowed amount, object, customer or action;
• cases where the correct response is to stop or escalate.

For every case, define the expected final state and the allowed process constraints.

Anthropic’s evaluation guidance separates a task, a trial, a grader, a trace and an outcome. That vocabulary is useful because agents can take different valid paths. Score the final state and the critical constraints, not whether the agent produced one preferred chain of steps.

Use multiple trials where output can vary. Read traces. A high average can hide a recurring severe failure, and an automated grader can reward a convincing explanation when the downstream state is wrong.

Deliverable: a versioned evaluation set with outcome graders, safety assertions and an initial non-agent baseline.

5. Days 31-45: build the simplest sufficient system

Implement in layers:

1. Evidence layer: approved sources, freshness, access and citations.
2. Tool layer: narrow operations with clear input and output contracts.
3. Workflow layer: known sequence, deterministic checks and explicit branches.
4. Agent layer: model-directed path selection only where cases genuinely need it.
5. Execution layer: independent validation of identity, authority, target, parameters and approval before any consequential write.

The model should propose an action. A deterministic execution service should decide whether the proposed action is currently allowed.

OWASP’s AI Agent Security guidance recommends separating decision-making from execution and validating scope, privilege and approval. NIST’s 2026 identity-and-authority concept paper names identification, authorisation, auditing, non-repudiation and prompt-injection controls as core agent questions. The NIST work is a concept paper, not a final standard.

Make failures explicit:

• missing source means stop;
• ambiguous target means stop;
• expired identity means stop;
• unavailable approval means stop;
• tool response outside its schema means stop;
• partial commit means reconcile before retry.

Deliverable: a supervised system that passes the evaluation set and cannot execute beyond its defined boundary.

6. Days 46-60: run a shadow pilot

In shadow mode, the system processes live-like cases without changing production state.

Compare:

• proposed outcome versus actual outcome;
• time to proposed outcome;
• source and tool failures;
• exception classification;
• human correction;
• repeated failure patterns;
• cost per case;
• model and tool variability;
• result by case type, not only as one average.

Shadow mode is not risk-free. Real customer, employee, financial or health data still needs an approved access and retention design. But it lets the team observe decisions before giving the system authority.

Do not tune only to the shadow sample. Maintain a held-out evaluation bank and keep severe failure classes visible even when their frequency is low.

Deliverable: an error taxonomy, measured cost per case and a decision on which actions may enter a controlled production pilot.

7. Days 61-75: release one bounded action

Choose the least consequential action that still tests the operating system around the model.

Good first production boundaries include:

• create a draft but do not send;
• create a proposed transaction but require exact approval;
• route a case but do not change entitlement;
• update one non-financial field from an approved source;
• execute within a low-value policy envelope with independent checks.

Give the agent a dedicated identity. Authorise each tool operation at execution time. Bind human approval to the exact target, parameters and expiry. Retain the relevant evidence, proposed action, approval, tool request, tool result and final state.

Set live stop conditions:

• any authority violation;
• repeated material error;
• unexplained cost spike;
• missing audit record;
• inability to reconcile final state;
• evaluation regression after a model, prompt, tool or data change.

The operator must know how to disable execution quickly without disabling observation or losing the evidence needed to investigate.

Deliverable: a limited production run with a named operator, live telemetry, incident path and tested kill switch.

8. Days 76-90: make a production decision

The decision is not “did the demo work?” Use four possible outcomes:

The calendar creates review cadence, not an entitlement to production. Advancement depends on evidence gates: lawful data use, representative evaluation, process-owner acceptance, security and privacy review, procurement readiness, change capacity, production ownership and tested recovery. Legal, procurement, data, security or workforce-change requirements may extend the work beyond ninety days. Day 90 is a decision point, not a promise of scaled deployment.

Re-run the AI Agent Business Case using pilot evidence rather than estimates. Include residual review, exception work, monitoring, control operations and failure cost.

Scaling should expand one dimension at a time:

• more volume with the same action;
• one additional case type;
• one additional data source;
• one additional tool;
• one wider authority envelope;
• one new business unit.

Changing all six at once makes the next failure impossible to attribute.

Deliverable: a signed decision record, updated business case, production owner and next evaluation boundary.

9. The minimum operating model

A production agent needs named ownership across six roles. One person may hold more than one role in a small programme, but the responsibilities must remain distinct.

“The AI team owns it” is not an operating model. The AI team can own components. It cannot own a refund policy, hiring outcome, production shutdown or statutory filing.

10. Readiness checklist

Start the 90-day fieldbook only when:

• ☐ one queue and one business owner are named;
• ☐ the final state can be observed independently of the model;
• ☐ a non-agent baseline exists or can be collected;
• ☐ the first action is reversible or requires exact approval;
• ☐ the organisation can provide a dedicated identity and narrow tool access;
• ☐ real cases can be used lawfully for evaluation;
• ☐ a process expert will grade outcomes and exceptions;
• ☐ the team can run in shadow mode;
• ☐ a production operator and kill-switch owner are available;
• ☐ a stop, redesign, continue or scale decision will be made on day 90.

If several are missing, the correct first deliverable is a workflow discovery sprint, not an agent.

11. Start small in consequence, not in seriousness

A bounded first action still needs production-grade thinking. Identity, evaluation, audit, intervention and cost are easier to design before a successful demo creates pressure to ship.

The goal of the first 90 days is not maximum autonomy. It is a trustworthy decision:

That is how an agent programme starts without becoming a platform programme in search of work.

Download the editable 90-day AI agent pilot fieldbook.

For the engineering layer that follows, read Context, Loop and Graph Engineering, or return to White Papers.

Sources and verification status

Checked 26 July 2026. OpenAI and Anthropic sources are vendor guidance. NIST’s agent identity-and-authority paper is a concept paper, not a completed standard.

• OpenAI, Identifying and scaling AI use cases – vendor guidance on work discovery and impact/effort prioritisation.
• OpenAI, A practical guide to building agents – vendor guidance on models, tools, instructions, guardrails and intervention.
• Anthropic, Building effective agents – vendor guidance distinguishing workflows from agents.
• Anthropic, Demystifying evals for AI agents – vendor guidance on evaluation design and outcome measurement.
• NIST NCCoE, Identity and Authority of Software Agents – 2026 concept paper and project proposal.
• OWASP Cheat Sheet Series, AI Agent Security – community security guidance on tool abuse, prompt injection, memory and execution controls.