Agentic AI

Agentic AI Development Services

Agents that keep working after the happy path ends

A demo agent has to work once. A production agent has to work on the ten thousandth run, on the malformed input, when a tool times out, and when the model changes underneath it. We build agent systems with evaluation harnesses, bounded retries, spend ceilings and step-level tracing, so you can tell whether it is actually working.

AI AGENTSLANGGRAPHMULTI-AGENTTOOL CALLINGEVALSGUARDRAILSOBSERVABILITY

Evaluated

Regression suites over recorded traces, run in CI

Bounded

Step, token and spend limits enforced on every run

Traced

Every step, tool call, retry and cost recorded

6–12 weeks

Typical range from scoped workflow to production

Why Zenthos

The demo works. That was never the hard part.

An agent that is right 95% of the time on a single step is right about 60% of the time across ten steps. That arithmetic does not appear in anyone’s pitch deck, and it is the most common reason pilots stall. A workflow that felt like magic on five hand-picked examples starts producing a long tail of half-finished runs the moment it meets real inputs — and because the failures are different every time, there is no bug to point at and fix.

The specific failure modes are boring, which is why they get skipped. Context grows with every tool result until the model quietly loses an instruction it was given twenty steps ago. A tool returns HTTP 200 with an empty body and the agent reasons confidently over nothing. A retry loop that looked harmless in testing spends a month of budget on one stuck input. And with no regression suite, a prompt edit that fixes one case silently breaks three others, which nobody discovers until a customer does.

We build agents the way you would build any other distributed system, because that is what they are. Explicit state and control flow instead of hoping the model remembers. Typed tool contracts that return errors an agent can recover from. Durable execution, so a run that dies at step seven resumes at step seven rather than paying to redo the first six. Per-run budget ceilings. And an eval harness over recorded production traces, so changing a prompt is a code change with a test rather than an act of faith. Non-determinism does not go away. It becomes something you can measure, bound and regression-test.

What We Deliver

Core Capabilities

[01]

Agent Architecture & Scoping

We decide which steps genuinely need a model and which are a function call wearing a costume. Most workflows want a deterministic pipeline with judgement at two or three points, not an autonomous agent — and that decision is worth more than anything downstream of it.

[02]

Multi-Agent Orchestration

Supervisor and worker topologies, state graphs, explicit handoff contracts and clear memory boundaries — built in LangGraph, the OpenAI Agents SDK or a plain state machine when the frameworks add more than they remove.

[03]

Tool & System Integration

Typed tools over your APIs, databases and SaaS systems, including MCP servers where the tools need to be reusable across frameworks. Idempotency keys, rate-limit handling and error surfaces the model can act on rather than hallucinate around.

[04]

Evaluation Harnesses

A labelled set of real cases, deterministic assertions where the answer is checkable, a calibrated judge where it is not, and trajectory evals over the steps themselves. It runs in CI, so a prompt change is reviewed like any other diff.

[05]

Reliability & Failure Recovery

Durable execution with checkpointed state, bounded retries with backoff, compensating actions for partial writes, and human escalation when a step exhausts its budget. Partial success is recorded as partial success, not reported as done.

[06]

Observability & Cost Control

Step-level tracing with token, latency and cost attribution per task, spend ceilings per run, caching where context repeats, and alerting on success-rate drift — so degradation shows up as a trend line before it shows up as a complaint.

How It Compares

Agent architectures compared

Three ways to build the same feature. The right answer is usually less exciting than the one that gets proposed.

Single agent + toolsMulti-agent orchestrationDeterministic workflow
Best whenThe task is open-ended but narrow — one domain, a handful of toolsGenuinely separate domains, roles or permission boundariesThe steps are known in advance and only one or two need judgement
DebuggabilityModerate — one trace to read, but the path differs every runHard — failures cross agent boundaries and blame is ambiguousEasy — a failed step is a failed step, at a known line
Cost per taskGrows super-linearly; the whole history is re-sent each stepHighest — coordination overhead plus context duplicated per agentLowest and predictable — model calls only where you put them
LatencySequential tool calls, typically seconds to a minuteWorst — handoff round-trips compoundBest; steps without data dependencies run in parallel
Failure modeLoops, context drift, or confidently stopping earlyHandoff ping-pong, deadlock, agents contradicting each otherA clean exception you can page on
Eval difficultyFinal output plus trajectory scoringHardest — each agent and every interaction between themOrdinary integration tests, plus scoring on the model steps
MaintenanceEvery prompt or tool change needs the regression suiteEach added agent multiplies the interaction surfaceNormal software maintenance

Most teams should start in the right-hand column. A deterministic workflow with one or two model-driven steps solves more real problems than either agent pattern, costs a fraction to run, and is the only one you can debug at 3am. Move to a single agent when the branching genuinely cannot be enumerated, and to multi-agent only after you have hit the context or permission limits of one. If a vendor proposes multi-agent in the first meeting, ask them what it breaks.

How We Work

Our Process

01

Workflow Teardown

We walk the workflow step by step, mark which steps actually need a model, and agree what “correct” means in terms someone can check. Some engagements end here with a recommendation not to build an agent. That is a legitimate outcome and a cheap one.

02

Evaluation Set First

Before any agent code, we assemble a few dozen real cases with labelled expected outcomes — including the ambiguous and malformed ones. Without this you cannot distinguish an improvement from noise, and every prompt change becomes a coin flip.

03

Build the Thin Version

The narrowest architecture that could plausibly work, usually a typed state graph with model calls at the branch points. Step limits, spend ceilings and tracing are wired in from the first commit, not added after the first incident.

04

Break It On Purpose

We inject tool timeouts, empty and malformed responses, rate limits and adversarial inputs, then verify the retry, compensation and escalation paths hold. We also test prompt injection arriving through tool results, because that is the realistic vector.

05

Ship, Trace & Hand Over

Deployment into your infrastructure, tracing and cost dashboards wired to your existing stack, the eval suite runnable in CI, and a runbook covering what to do when success rate drops. You own the code.

Tools & Technologies

Tech Stack

We choose the right tool for the job — not the trendiest one.

Python logoPython
LangGraph logoLangGraph
OpenAI Agents SDK logoOpenAI Agents SDK
Claude
Temporal
Langfuse
PostgreSQL
Redis
AWS logoAWS
Questions

Frequently Asked Questions

How long does it take to build a production AI agent?
A single well-scoped workflow — one domain, a handful of tools, a human reviewing the output — is usually six to eight weeks from kickoff to production, including the evaluation harness. Broader systems with write access, approval gates and more than one upstream integration run ten to twelve. The agent code is rarely the long pole. Agreeing what “correct” means and assembling a labelled evaluation set is.
Why do most AI agent pilots never reach production?
Four reasons, roughly in order. Per-step accuracy compounds, and nobody sized the workflow for it — 95% per step is about 60% over ten steps. There is no evaluation set, so “it seems better” is the only available measure and every change is a gamble. Cost and latency were measured on a happy-path demo, before retries, long context and error handling. And the pilot was scoped to a demo rather than to a workflow someone is accountable for, so there is no owner to push it over the line. The first two are engineering problems and we fix them. The last two are scoping problems, and they are the ones that actually kill projects.
Should we build a custom agent or buy an off-the-shelf platform?
Buy when the workflow is generic: meeting summaries, triage on a standard helpdesk, Q&A over a common document store. Vendors do those well and rebuilding them is a poor use of your engineering budget. Build when the workflow touches systems only you have, when the decision logic is the thing that differentiates you, or when the traces, evals and cost controls need to live inside your own infrastructure. A lot of teams should buy, and we will tell you when you are one of them.
How do you evaluate an agent?
Three layers. Final-output scoring against a labelled set of real cases, using deterministic assertions where the answer is checkable and a calibrated judge model where it is not, with a human-labelled subset to keep the judge honest. Trajectory evals over the steps: did it select the right tool, in a sensible order, without looping or stopping early. And production monitoring of task success rate, escalation rate, and cost and latency per task, tracked over time so drift appears as a trend. The suite runs in CI and gates releases.
How do you handle failures, timeouts and retries?
We assume every tool call can fail, hang, or return something plausible and wrong. Tools are made idempotent wherever the upstream system allows it, so a retry cannot double-charge or double-send. Retries are bounded with backoff, and a step that exhausts its budget escalates to a human instead of looping. Run state is checkpointed, so a failure at step seven resumes at step seven rather than paying to redo the first six. Partial success is recorded explicitly — what completed, what did not — rather than being reported as a clean finish.
What does an agent cost to run in production?
Architecture drives this far more than model pricing does. The dominant cost in most agent systems is re-sending a growing context on every step, so a ten-step run can cost many times a single call with the same starting prompt. We instrument cost per task from the first week, cap spend per run, cache where context repeats, and route mechanical steps to smaller models — a frontier model deciding which of four tools to call is usually not where the value sits. If you want a real number before committing, the fastest route is to build the thin version and measure it.
Do we own the code?
Yes. Agent code, tools, evaluation suite, tracing configuration and runbook all ship into your repository. There is no runtime dependency on Zenthos, no per-seat licence, and no hosted black box you cannot inspect. Retainer support is available if your team wants it, and plenty of clients do not need it.
Do you work with companies in the US, UK and EU?
Most of our engagements are with teams there. We keep overlapping hours with both US coasts and European time zones, and we are used to working inside client security reviews, DPAs and procurement processes. Where data residency matters, agents run in your own cloud account and region, and model providers and data flows are agreed in writing before anything is built.
Insights

Related Articles

View all →

Have an agent pilot that stalled?

Send us the workflow and the point where it breaks. We will tell you whether it needs an agent, a deterministic pipeline with one model call, or nothing at all — before anyone signs a statement of work.