AI agent development

When you need this

• You have a working agent demo in a notebook or a single script, and the first real users exposed retries that loop, state that disappears between turns and tool calls that fail silently.
• Your product needs to take actions in other systems, such as tickets, a CRM or internal APIs, and every action has to be logged, permissioned and possible to review afterwards.
• The agent framework was chosen a year ago by an engineer who has since left, and nobody on the team can say what happens when a run is interrupted in the middle of a tool call.
• You are deciding between a single prompt with function calling and a multi-step orchestrated agent, and you want that decision made from the failure cases rather than from opinion.
• Token cost per conversation climbs with every tool you add, and there is no per-call accounting that shows where the spend goes.

What you get

• LangGraph orchestration graph with typed state, a checkpointer and explicit interrupt points
• State and retry handling for every node, including resumable tool turns
• Tool-calling hardening: schema-validated inputs, timeouts, idempotent actions and a tool-call ledger
• MCP integration so the agent reaches external tools through standard connectors rather than one-off wrappers
• RAG integration where the agent needs grounded context from your documents or database
• Evaluation tests covering expected trajectories, tool failures and refusal cases
• Docker deployment with a compose file or an equivalent your team already runs
• Documentation: architecture notes, a runbook for stuck and interrupted runs, and a guide to adding a tool

Outcomes

• An agent whose every tool call is written to a ledger and can be resumed after a crash, a timeout or a user pause, instead of being replayed from the start.
• Tools that require explicit user consent before they run, so the agent cannot take an action nobody approved.
• Clear boundaries between orchestration, tools, retrieval and model access, so your team can swap a model or add a tool without editing the graph.
• A test suite that encodes the agent's expected trajectories and failure handling, runs in CI, and serves as the acceptance criteria for the sprint.
• Per-token cost accounting per run, so you know what a conversation costs before you scale it, and a written note on where semantic caching or model routing would cut it.

How it works

1. 1

   20-minute technical call

   We go through what the agent must do, which systems it touches, what has already been built and where it fails today. If you have the code, a trace or a recording of a failing run, I read it before we talk so the call is spent on decisions.

2. 2

   Written diagnosis

   You receive a written diagnosis: where state is lost, which tool calls are unsafe to retry, what the retrieval path actually returns, whether the orchestration is doing work a plain function could do, and what a run costs in tokens. It is written to be useful even if you stop here.

3. 3

   Fixed-scope proposal

   Scope, timeline and price in writing under the AI Agent Engineering Sprint, starting at $1,200 for 7–10 working days. The scope names the tools, the graph nodes and the tests that define done, so there is no argument later about what finished means.

4. 4

   Implementation and handover

   I build the agent in your repository or a fresh one, with the tests as acceptance criteria. Handover is the code, the documentation and the runbook, plus a walkthrough with your engineers so they can extend the agent without me.

Proof: what I built

• In OmidGPT I built the agentic tool-calling runtime: resumable tool turns, a tool-call ledger, per-tool user consent and MCP connectors behind an OAuth / MCP relay. The platform exposes 209 API endpoints, serves multiple model providers and accounts for cost per token.

  Read the OmidGPT case study

• In Jozveh-AI a LangGraph supervisor coordinates eight agents that turn source material into cited study documents. The pipeline is covered by 673 tests across 77 files, which is the model I follow for acceptance tests in client sprints.

  Read the Jozveh-AI case study

• For AiMatin I built a custom Node.js MCP server through which an AI operator runs admin workflows, such as coupons, popups, funnel automations and reports, against a FastAPI and PostgreSQL backend.

  Read the AiMatin case study