Squads that get agents into production
Small dedicated teams building bespoke autonomous agents inside your own entity, with evaluation and observability treated as the core engineering problem rather than an afterthought.
Agentic systems fail in evaluation, not in the model
The demo is rarely the hard part. What separates a prototype from a production agent is knowing, continuously and specifically, whether it is working.
Agent architecture
Tool definitions, planning strategy, memory and the orchestration between steps. The design decisions here determine cost, latency and failure behaviour far more than the choice of model does.
Evaluation harness
Offline evaluation sets, regression suites and a failure taxonomy. This is the most important component and the one most commonly absent, which is why so many agents never leave the prototype stage.
Observability and tracing
Full traces of every run, with the inputs, tool calls, intermediate reasoning and outcome captured. Without this, debugging an agent in production is guesswork.
Tool and system integration
The connections into your actual systems, where most of the real engineering effort lives. An agent is only as capable as the tools it can reliably call.
Guardrails and safety
Input and output validation, permission boundaries, cost ceilings and human in the loop checkpoints where the action is consequential or irreversible.
Cost and latency control
Token budgets, caching, model routing and step limits. Agentic systems fail commercially long before they fail technically, usually through unbounded loops.
A squad, not a proof of concept team
An agentic squad is typically four to eight people. A lead engineer who owns architecture and evaluation strategy, two or three engineers who have taken systems into production, a data or platform engineer, and someone who owns evaluation full time.
That last role is the one companies leave out, and leaving it out is the single most reliable predictor that the system will stall between demo and deployment. Knowing whether an agent is working is a full time engineering problem, not something the team does at the end.
Because the squad sits inside your own entity, the models, prompts, evaluation sets and tooling are your intellectual property. This matters more in agentic work than in most engineering, because the evaluation sets and failure taxonomy you accumulate are the genuinely durable asset.
Dedicated squad, consultancy engagement, or hiring locally
| Dimension | Dedicated squad (Nano GCC) | AI consultancy | Hiring in your home market |
|---|---|---|---|
| Who owns the evaluation sets | You | Usually shared | You |
| Who owns the IP | Your entity | Contract dependent | You |
| Continuity after launch | Permanent team | Ends with engagement | Permanent |
| Time to a working squad | 3 to 4 months | 2 to 4 weeks | 6 to 12 months |
| Fully loaded cost per engineer | Lowest | Highest | Highest |
| Senior AI talent availability | Deep pool in India | Vendor allocated | Severely constrained |
| Knowledge retained in house | Yes | Rarely | Yes |
| Suitable for long lived systems | Yes | No | Yes |
Effort distribution on a production agentic system
This distribution consistently surprises teams whose expectations were set by a prototype.
How a squad is stood up
Lead engineer hired
The constrained hire, brought in first, who then participates in every subsequent interview. Genuine production experience with agentic or machine learning systems is worth waiting for rather than substituting.
Use case scoped and evaluated
A specific, bounded use case chosen with a measurable success definition and an evaluation set built before implementation begins. Choosing the wrong first use case is the most common failure and the most expensive.
Squad completed
Engineers with production experience, a data or platform engineer, and a dedicated evaluation owner. Deliberately not hired all at once, so the lead can calibrate the bar.
First system in production
A narrow agent in real use with full tracing, guardrails and a cost ceiling, rather than a broad one in a demo environment. Narrow and deployed beats broad and pending.
Expansion on evidence
Additional use cases added once the evaluation harness and operational patterns are proven, reusing the infrastructure rather than rebuilding it each time.
Why an owned squad suits agentic work specifically
Evaluation sets stay yours
The evaluation data and failure taxonomy accumulated over a year are the durable asset in agentic work. In a consultancy engagement these frequently walk out of the door at the end.
Failure knowledge compounds
The engineers who debugged last quarter’s failure mode are the ones designing around it now. Agentic systems fail in specific, learnable ways, and that knowledge does not transfer through documentation.
Cost is predictable
A fixed team cost rather than a day rate that scales with scope, which matters in a field where scope genuinely does expand as you learn.
Access to a deep talent pool
India has one of the largest pools of engineers with production machine learning experience, at a fully loaded cost that makes a dedicated squad viable rather than exceptional.
A squad, and the infrastructure that makes it productive
The squad is the deliverable, but what makes it effective in month six is the evaluation and observability infrastructure built in month two.
- A lead engineer with genuine production experience in agentic or machine learning systems
- Engineers who have operated systems in production, not only prototyped them
- A dedicated evaluation owner, the role most commonly missing and most reliably decisive
- An offline evaluation set and regression suite built before implementation begins
- Full run tracing capturing inputs, tool calls, intermediate steps and outcomes
- Guardrails, permission boundaries and human in the loop checkpoints for consequential actions
- Token budgets, step limits, caching and model routing with hard cost ceilings and alerting
- A documented failure taxonomy that accumulates as institutional knowledge rather than tickets
When a dedicated squad is right, and when it is not
A good fit when
Agentic capability is intended to be a durable part of your product rather than an experiment, the evaluation sets and failure knowledge you accumulate have real value, and you want that knowledge retained in house across model generations.
A poor fit when
The task is well specified, deterministic and high volume, where conventional automation is cheaper and more reliable. Also when you want a single proof of concept and nothing after it, which a consultancy will deliver faster and at lower commitment.
One honest caveat. Agentic AI is not the right tool for every problem, and a squad will tell you so faster than a vendor will. If the task is well specified, deterministic and high volume, conventional automation is cheaper, more reliable and easier to reason about. We would rather scope a smaller agentic surface that reaches production than a broad one that stalls in evaluation.
Frequently asked questions
What size squad do we actually need?
Four to eight people for a first production system. A lead engineer, two or three engineers with production experience, a data or platform engineer, and a dedicated evaluation owner. Smaller than four tends to mean evaluation gets skipped, which is the failure mode that matters.
Why is evaluation treated as the central problem?
Because agentic systems fail in ways that are not obvious from the output. An agent that is right eighty percent of the time and confidently wrong the rest is worse than no agent, and you cannot tell which is which without an evaluation harness. It is the difference between a demo and a deployment.
Do we own the models, prompts and evaluation sets?
Yes. The engineers are employed by your Indian entity with IP assignment in their contracts, so the architecture, prompts, tooling and evaluation data vest in you directly. There is no vendor in the chain of title, which matters most for the evaluation sets, since those are the hardest asset to rebuild.
How do you control the cost of running agents?
Token budgets per run, step limits, caching, model routing so that cheaper models handle simpler steps, and hard cost ceilings with alerting. Unbounded loops are the most common way agentic systems become commercially unviable, and the controls belong in the architecture rather than in a dashboard.
Can the squad work with our existing machine learning team?
Yes, and this is the common pattern. The India squad typically owns the agentic layer, evaluation infrastructure and integration work while your existing team retains model and data ownership. Boundaries are agreed at the start rather than negotiated later.
What is a realistic first use case?
Narrow, internally facing, with a measurable success definition and tolerance for error. Retrieval over internal documentation, triage and routing, or structured extraction are good starting points. Customer facing and irreversible actions should come after the evaluation harness has proven itself.
How long until something is actually in production?
Four to six months from squad formation to a narrow agent in real use, assuming the entity is being set up in parallel. Anyone promising production agentic systems in six weeks is describing a prototype, which is a different thing and will not survive contact with real inputs.
What if the technology changes underneath us?
It will, which is an argument for owning the squad rather than against it. Model choice is the most replaceable layer in the system. Evaluation sets, integration work and operational knowledge are the durable parts, and a permanent team carries those across model generations.
Related reading
Scope an agentic squad
Tell us the use case you have in mind and what a good outcome would look like. We will come back with a squad shape, a realistic path to production, an evaluation approach and a fully loaded cost.