Skip to main content

A.G.E.N.T., a five-phase method for building and operating production AI agents.

A.G.E.N.T. is the delivery method for agent engagements within our broader AI services practice. Each phase produces a concrete artifact, and those artifacts gate progress. Engineering, evaluation, and instrumentation still iterate as the work develops.

01

Why this framework exists

AI planning and production readiness answer different questions: is this agent ready for real work?

Portfolio planning helps a company choose where to invest and how to organize the work. A.G.E.N.T. begins once a selected workflow may require an agent. It tests whether the system can meet its operating requirements.

Production readiness depends on more than a demo. Data, integrations, system behavior, human review, and adoption all affect whether an agent can handle the workflow.

Engineering evidence guides the build. Evaluation results and traces show where tool design, prompts, state, or error recovery need to change.

Some failures stay hidden without monitoring. Models change, prompts get edited, and input distributions shift. Scheduled evaluations and traces show when yesterday's result no longer holds.

The workflow team has a direct role in the build. A central AI group can supply standards and expertise, while the people closest to the work define correct results and the exceptions that matter.

A.G.E.N.T. organizes the work around the artifacts an engineering and operations team need to ship and run one production agent.

02

The five phases

The five phases.

The phases have a clear order, but work inside them can overlap. Each one produces an artifact that shows when the engagement is ready to advance.

Phase 01

Anchor

Commit to one bounded workflow with a measurable baseline.

Choose one workflow and name the person who owns it today. The current process gives us a baseline for comparing the agent. If you cannot describe the workflow's inputs, outputs, and current cost, the engagement is not ready.

Artifact

A one-page workflow spec containing the trigger event, the inputs, the outputs, the current baseline (who does this today, how long it takes, error rate if known), and the success criteria that define what 'good enough to deploy' means in numbers.

Failure mode it prevents

Scope creep during anchoring. The conversation drifts from 'this workflow' to 'and it should also handle…'. The written artifact keeps the scope concrete, so week six does not relitigate week one.

Self-check

Can we describe the workflow in two sentences without using the words 'platform,' 'intelligence,' or 'automation'?

Phase 02

Ground

Build the eval set before building the agent.

We collect a representative set of real workflow examples with accepted outputs or review criteria. The size depends on the variation and risk in the work. Together, we define what "working" means in measurable terms such as accuracy, latency, cost per run, or escalation rate. Without this step, a good demo cannot tell you whether the agent is improving or just getting lucky.

Artifact

A runnable evaluation harness. Your team can execute the script, run the agent against the evaluation set, and produce a scorecard. The harness is ready early enough to guide development and stays with you.

Failure mode it prevents

Treating evaluations as a final QA step. The evaluation set is the working specification for the agent. Building the harness first exposes gaps in that specification before we write code against it.

Self-check

If the agent passes the eval set perfectly, does the workflow actually work in production? If no, the eval set is incomplete.

Phase 03

Engineer

Build the minimum agent that passes the eval.

This phase covers tool design, model and prompt iteration, system integrations, state management, and error recovery. We start with the smallest architecture that can plausibly pass the evaluation. A node gets added only when a failure calls for it. Extra state, unnecessary node splits, missing loop-back edges, and premature abstractions all add surface area without improving the score.

Artifact

A working agent that scores acceptably on the eval set, against the success criteria from Anchor, with traces visible for every run.

Failure mode it prevents

Optimizing for the demo instead of the evaluation. An agent can look impressive in a meeting and still degrade under real traffic. The evaluation keeps the build tied to the actual workflow.

Self-check

If we removed any single node, tool, or state field, would the eval score drop? If not, remove it.

Phase 04

iNstrument

Production observability before production traffic.

Every run produces a trace, and failures include enough context to reproduce them. We track cost per run and schedule evaluations against production samples so the operator is alerted when scores move. A prototype can work before the team has a reliable way to monitor it. This phase adds that monitoring before the agent handles production traffic.

Artifact

A dashboard your operator checks daily, an alerting rule that fires on regression, and a runbook for what to do when it fires.

Failure mode it prevents

Treating observability as optional infrastructure. If the operator cannot find yesterday's failure rate without running a custom query, the instrumentation is not done.

Self-check

If the agent's accuracy dropped ten percent tomorrow, how would your team find out? If the answer is 'a customer would tell us,' instrumentation isn't done.

Phase 05

Transfer

Choose a clear operating model for the system.

Transfer defines who edits prompts, extends the evaluation set when new failures appear, approves model upgrades, and owns the runbook. Your team may run the agent independently, or MavenSolutions can operate it with you under a managed service. In both cases, your team retains access to the code, evaluations, configuration, and operating records.

Artifact

A documented operating model. It covers the code, evaluations, configuration, runbook, escalation process, and the people responsible for each decision. The same material supports an independent handoff or a managed service.

Failure mode it prevents

Unclear ownership after launch. If no one knows who responds to a regression or approves an update, production support has not been designed.

Self-check

If the agent regressed tomorrow, would everyone know who responds and how? If not, transfer is not done.

03

Controls across every phase

Production controls start before production.

The five phases organize delivery. These controls shape the design and the evidence used to approve it at every phase.

01

Privacy, security, and governance

Define which data the agent may read, what actions it may take, how identities and permissions are checked, and what the logs must retain.

02

Data and integrations

Test source quality, access rules, system contracts, and failure behavior before the workflow depends on them. Name an owner for each dependency.

03

Human review

Set the decisions an agent may make, the conditions that require approval, and the context a reviewer needs to act.

04

Models and reliability

Compare models and providers against the evaluation set, including quality, cost, latency, availability, and the effort required to change providers.

05

Adoption and operations

Operators help define correct results, practice the runbook, and learn how to report new failures before handoff or managed operation begins.

04

How the phases sequence in a delivery engagement

The five phases fit into three working stages.

The schedule below illustrates one thirteen-week build for a qualified, bounded workflow. Actual timing depends on the available data, required integrations, security review, and amount of human review. Engineer and iNstrument overlap because monitoring starts during engineering. The artifacts mark progress more reliably than the calendar.

Stage 1

Weeks 1 to 3

Anchor and Ground

The workflow specification is signed and the evaluation harness is running, so your team can score the agent before development begins.

Stage 2

Weeks 4 to 9

Engineer

The working agent passes the evaluation, each iteration is visible in traces, and the architecture stays small.

Stage 3

Weeks 10 to 13

iNstrument and Transfer

The dashboard and alerts are live, and the agreed handoff or managed operating model is in place.

05

Framework boundaries

A.G.E.N.T. has a specific job.

It is for a selected agent opportunity.

A.G.E.N.T. begins after a workflow is selected and an agent is a plausible solution. AI opportunity prioritization, portfolio planning, data readiness, and solutions that do not need an agent follow other paths in our AI services practice.

It is one method in a broader practice.

MavenSolutions uses A.G.E.N.T. for production agent work. It is not a licensing or certification program. We publish it so prospective clients can examine the method before an engagement.

Engineering judgment still matters.

The framework structures the work. Someone still needs to read traces, edit prompts, and recognize when the architecture has become more complex than the problem requires.

Discuss an AI project

Start with the question you need answered.

If you have selected a workflow, we can assess whether an agent and the A.G.E.N.T. method fit. If you are still comparing AI opportunities, we can help prioritize the first one.
Forty-five minutes to clarify the decision and whether we can help.