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.
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
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 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
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
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
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
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
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
The five phases organize delivery. These controls shape the design and the evidence used to approve it at every phase.
01
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
Test source quality, access rules, system contracts, and failure behavior before the workflow depends on them. Name an owner for each dependency.
03
Set the decisions an agent may make, the conditions that require approval, and the context a reviewer needs to act.
04
Compare models and providers against the evaluation set, including quality, cost, latency, availability, and the effort required to change providers.
05
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 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
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
The working agent passes the evaluation, each iteration is visible in traces, and the architecture stays small.
Stage 3
Weeks 10 to 13
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. 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.
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.
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.