AI EngineeringAgents & Agentic Workflows
Agent Prototype Sprint
A working agent prototype for one bounded workflow in staging, with documented system boundaries and a repeatable evaluation baseline that supports a proceed, revise or stop decision.
Agent Prototype Sprint
$25K–$45K
- Duration: 2–3 weeks
- Tier: Build
- Format: Fixed scope
You leave withWorking agent prototype in staging with architecture docs and an evaluation baseline
Book a Free SessionSound familiar?
We think an agent could remove a painful step in our product, but a polished demo will not tell me whether it handles real customer variation. I need to see the failure cases, integration effort and cost before I commit a team or promise a launch.
The use case looks promising, but I need to know which data the agent reads, which systems it can change and where a person approves its actions. I need a result my platform, security and business teams can inspect before we fund production work.
We have a manual workflow spread across a few systems. I want to test whether an agent can handle the common path and hand off exceptions without creating another system my team has to babysit.
What you leave with
Agent prototype
Format: Source in client-approved repository, deployed to staging
How we know it’s acceptableRuns the agreed workflow; allowed tool actions, approval path and defined failure behavior can be demonstrated.
Architecture pack
Format: Markdown/PDF and editable diagram
How we know it’s acceptableShows component and trust boundaries, data flow, tool contracts, permissions, approval points, observability and known limitations.
Evaluation set and baseline
Format: Versioned cases, runnable scripts and result report
How we know it’s acceptableClient team can rerun the cases; results include denominators, failure categories, escalations, latency and cost where measurable.
Handover and recommendation
Format: Demo, setup notes and decision memo
How we know it’s acceptableClient technical owner can start and inspect the prototype; memo identifies evidence, unresolved risks and conditions for a production decision.
How it runs
2–3 weeks
Days 1–3
Establish the decision and design
Confirm the workflow owner, current process, success criteria, failure costs and representative cases. Map data and trust boundaries, tool contracts, permissions and approval points.
OutGate: client accepts the bounded scope, staging access and evaluation plan before build starts.
Week 1–2
Build an observable vertical slice
Implement the shortest end-to-end path through the agreed integrations, then add bounded execution, input/output validation, human approval for consequential actions and traces that identify each tool call.
OutGate: the workflow runs in staging and its failure paths are visible.
Week 2–3
Evaluate, fix and hand over
Run normal, edge, denied-permission and tool-failure cases against the versioned set. Address agreed critical defects, rerun affected cases and record remaining gaps. Transfer code, setup notes, architecture and results.
OutGate: the client can rerun the baseline and decide to proceed, revise or stop.
Is this right for you?
This is for you if
- BuyerThe leader accountable for making an agent workflow useful: a startup CTO or founder, an enterprise engineering or product owner, or an operations leader with a technical sponsor.
- Also has to say yesWorkflow owner: Defines the task, acceptable outcomes and cases that must be reviewed by a person.
- Also has to say yesTechnical owner: Approves integration, hosting and handover boundaries.
- Also has to say yesSecurity and data owners: Approve staging access, data use and permitted tool actions where required.
- Also has to say yesBudget owner: Approves the fixed scope and investment.
This is the wrong answer if
- The workflow is wholly deterministic and a conventional integration or rules engine is simpler to maintain.
- The client needs a production service, live customer rollout, support commitments or broad security assurance within this engagement.
- No workflow owner can define success, provide representative examples or review results during the sprint.
- Required systems, APIs or safe test access are unavailable within the 2–3 week window.
- The proposed actions cannot be safely bounded, approved or reversed in staging.
- The client already has a working prototype and needs production hardening or scale work instead.
What’s included, and what isn’t
In scope
- One agreed workflow in one staging environment, with up to two agreed integrations.
- Defined inputs, outputs, tool permissions and action limits; consequential writes need an agreed approval and recovery path.
- A versioned evaluation set, baseline results, architecture pack and technical handover.
- The signed scope fixes integration count, allowed actions, evaluation cases and acceptance criteria before build.
Out of scope
- Production deployment, unrestricted or irreversible agent actions, additional workflows and client-system API development.
- Historical data cleanup, formal security certification, ongoing operation and support after handover.
Before we start
Before day one
- Decision ownership: A workflow owner can approve representative cases and success criteria; a technical owner can approve design and access decisions.
- Bounded workflow: Inputs, outputs, allowed agent actions, human approval points and unacceptable failures are agreed.
- Test material: Representative, legally usable normal and failure cases are available; the team knows the current manual or automated baseline.
- Staging access: Repository, environment, integration documentation, sandbox credentials and least-privilege permissions are ready and verified.
- Security and delivery path: Data-use approval is recorded; the client names an escalation contact and a change decision path if access or scope changes.
What we’ll need from your team
- Workflow owner or domain expert - 2–3 hours per week: Supplies real cases, labels acceptable outcomes and reviews failures. More time is needed if the process is undocumented.
- Platform or integration engineer - 3–4 hours per week: Provides sandbox access, API/schema answers and deployment help; verifies tool permissions with our engineer.
- Security or data owner - 1–2 hours in week one, then on call: Approves data use, identity boundaries and any write or approval path.
- Technical decision-maker - available within one business day: Resolves design or scope trade-offs that would otherwise block the build.
- These are planning estimates; the kickoff confirms the named people and availability.
Pricing
What we need to give you a quote
- The one workflow, current process, users, expected volume and cost of a wrong action.
- Named systems, API or integration documentation, identity model and staging constraints.
- Permitted read and write actions, approval points, data sensitivity and security requirements.
- Representative normal, edge and failure cases, plus a workflow owner to judge results.
- A technical contact and decision-maker who can resolve access and scope questions promptly.
After we hand over
Who owns it after we leave
Engineering owner: Accepts the repository, setup notes, staging credentials and rerunnable evaluation set at handover; owns access rotation and technical maintenance thereafter.
Workflow owner: Owns the decision on failed and escalated cases and the operational effort of reviewing them.
Sponsor or product owner: Accepts the decision memo, names the next decision date and funds any production work separately.
The project manager records these owners and acceptance at handover. If an owner is missing, the handover remains open as a decision, not an implied support commitment.
What we measure
- Senior Project Manager — decision and value: Agree the business decision, current process baseline, delivery milestones and accountable owner at kickoff. Compare elapsed handling time and human review effort only where the client can measure both before and after.
- AI Solutions Architect — system behavior: Record task completion, incorrect or unauthorized actions, escalation, latency and cost per completed task. Break results down by workflow path and integration; document tool failures, access boundaries and design changes needed for production.
- Senior AI Quality Engineer — evidence quality: Version the cases and scoring rules; include normal, edge, permission-denied and adversarial inputs. Report case counts, pass/fail criteria, reproducibility and unresolved defects. A small staging set is an initial baseline, not proof of production performance.
A public case study needs a client-measured starting point, a comparable later measure and explicit permission to use the outcome.
What comes next
- Agent Scale LaunchWhen the prototype meets agreed criteria and the client wants production controls, operations and rollout.
- Eval Harness SprintWhen the client needs repeatable evaluation in CI across future changes.
- A second prototypeOnly for a distinct workflow with its own decision and scope.
Questions buyers ask us
The deliverable runs in staging. Its results show what remains before a production launch, including security, operations and rollout work.
You may. This sprint adds explicit tool and data boundaries, observable execution and rerunnable tests, so your team can inspect the result beyond a scripted demonstration.
We agree on least-privilege staging access or safe fixtures before starting. If neither is possible, we should not sell this sprint as a working integration.
We report failure categories and the conditions that trigger them. A recommendation to narrow or stop is a valid outcome; the sprint does not promise that every workflow suits an agent.
Integration effort, data controls and action risk vary. We agree the boundaries and give you a fixed quote before work starts.