Jahanzaib

AI agent development services: AI agents that do the work. You approve.

I build custom AI agents that answer your calls, clear your inbox and run your back office. Live in weeks, and every line of code is yours to keep.

  • 126 systems in production
  • Live in about 3 weeks
  • The code is yours

Agents I have shipped into production

Watch one run

It does the work. It asks before anything risky.

A support agent, slowed down so you can follow it. Every step is logged.

support-agent · live run

Example

D

Dana R. · support inbox

My order #4417 arrived damaged. Can I get a refund?

Checking the order and the customer first

orders.get(4417) Delivered damaged, $120
crm.lookup(dana) 3 years, no refunds

Approved by Sam

Refund $120 to Dana?

ApprovedEdit
Reply sent, refund issued, 7 steps logged

What I build

Four agents I build again and again

Something else in mind? Tell me the job and I will scope it.

The short answer

What is AI agent development?

AI agent development is building software that reads a request, plans the steps, and takes real actions in your systems (your inbox, CRM, database or phone line) instead of only replying with text. A production agent also knows when to stop and ask a person. The work is the agent plus everything that makes it safe to run: the tool layer, the eval set, the approval gate and the monitoring.

  • Chatbot

    Answers questions in a chat window. It cannot change anything in your systems.

    Good for FAQs and simple support.

  • Workflow

    Runs the same fixed steps every time a trigger fires.

    Cheaper and easier to test when the steps never change.

  • AI agent

    Decides the steps per case and acts through your tools, with approval on anything risky.

    Right when every case needs a judgment call.

Where agents earn their keep

Six jobs I hand to agents most often

A glass shield deflecting sparks away from a glowing AI core

How it runs

Built safe. Yours to keep.

Six guardrails ship with every agent, so it can act on real data without acting on its own judgment alone.

  • Eval set from your real cases
  • Scoped keys, no admin access
  • Approval on anything risky
  • Spend cap on every run
  • Every step traced
  • One click kill switch

Your repo. Your cloud. Your keys.

How a build runs

From first call to a live agent

Delays rarely come from the model. They come from waiting on system access, a security review, or a decision about what the agent may do alone. I ask for all three in week one.

  1. Week 1

    Map the work and decide what it may do alone

    I sit with the people who do the job today and walk through real cases, including the ugly ones. Then I write down every action the agent could take and sort each into: does it alone, asks first, drafts only, never touches.

    You get: A one page agent spec with the autonomy level for every action and the pass bar for launch

  2. Weeks 1 to 2

    Build the eval set before the agent

    Your past cases become test cases with expected outcomes, including the ones where the right answer is to stop and ask. This is how you and I will both know whether it works, instead of trusting a demo.

    You get: An eval set of your real cases, agreed pass criteria, and a baseline score

  3. Weeks 2 to 3

    Tools, guardrails and the agent itself

    The permissioned tool layer first, then input validation, the approval gate, step and spend limits, and the planner on top. The eval set runs on every change, so a fix for one case cannot quietly break ten others.

    You get: A staging agent passing the eval set, with every tool call traced

  4. Weeks 3 to 4

    Shadow mode, then a limited launch

    The agent runs alongside your team on live work and its output is compared with what your people actually did. When it clears the bar, it goes live behind a switch on a slice of real traffic.

    You get: A shadow mode report and a written go or no go call

  5. Handover

    Runbook, walkthrough, and the keys

    A runbook for the failures I have seen, architecture notes, dashboards and alerts wired to your team, and a recorded walkthrough for whoever will own it next.

    You get: Repository, prompts, eval set, runbook and dashboards, all in your accounts

What is included

What you walk away with when the agent goes live

  • The agent, in your cloud

    Running in your account, calling models through your own API keys, so the usage bill goes to you at cost.

  • A permissioned tool layer

    Typed actions on your CRM, inbox, database and internal APIs. Each one narrow, rate limited and logged.

  • Guardrails you can inspect

    Input validation, scoped credentials, an approval gate on irreversible actions, step and spend limits, and a kill switch.

  • An eval set and report

    Built from your real cases with agreed pass criteria. Rerun before every model swap or prompt change.

  • Traces, dashboards, alerts

    Every tool call recorded with inputs, outputs and cost per run, and alerts on error rate and spend.

  • Runbook and handover

    Prompts under version control, architecture notes, a runbook for known failures and a recorded walkthrough.

The stack

Model agnostic on purpose, so a better or cheaper model is a config change

I pick the model per task on your eval results, not on a logo. The framework matters less than the eval set and the tool layer, and when a framework adds nothing I write plain Python.

  • Claude models

    Planning and drafting, picked per task on eval results

  • OpenAI and open models

    Where the eval says they win on cost or accuracy

  • LangGraph or Pydantic AI

    Agent loop and state, or plain Python when simpler

  • MCP

    Standard tool servers, so tools outlive any framework

  • Postgres and pgvector

    Memory and retrieval in your own database

  • AWS or your cloud

    Functions, queues and secrets in your account

  • Tracing and evals

    Langfuse, Logfire or your existing stack

  • Slack or your admin panel

    Where the approval gate asks a person

How engagements work

A fixed scope, quoted after one call

The price depends on how many systems the agent touches and how risky its actions are, so I quote it once I have seen the job.

  • Most teams start here

    One focused agent

    About 3 weeks

    One job, one or two systems, a clear pass bar.

    • Agent spec and eval set
    • Tool layer and guardrails
    • Shadow run, launch, handover

    Fixed scope after a call

  • Agent across many systems

    4 to 6 weeks

    Deeper integrations, more actions, or several agents working together.

    • Everything in a focused agent
    • More tools and approval rules
    • Dashboards and alerts for your team

    Fixed scope after a call

  • Ongoing build partner

    Month to month

    For teams with a backlog of agents, or one that needs to keep improving.

    • New agents as you need them
    • Model swaps checked against the eval set
    • Upkeep and monitoring

    Fixed scope after a call

Your options

Four ways to get an agent built, compared honestly

Each option trades speed, control and continuity differently. In house wins once you have several agents to run and someone to own them; until then, here is how they compare.

Who builds it

Working with me
Me, start to finish. The person on the call writes, tests and reviews the code.
Agency
A team behind an account manager; who actually builds it varies by project.
Freelancer
One person; quality depends entirely on who you find.
In house hire
Your hire, once you have recruited and onboarded one.

Guardrails and evals

Working with me
Shown, not claimed: the eval report, the approval screen and the traces are deliverables.
Agency
Usually listed on the sales page; rarely shown as artefacts you can inspect.
Freelancer
Rarely formalised.
In house hire
As good as your team’s practices.

Ownership and exit

Working with me
Code, prompts, eval set and accounts in your name from day one. A runbook so you can stop paying me.
Agency
Often transferred at final payment; check who holds the model and cloud accounts.
Freelancer
Depends on the agreement and where the repository lives.
In house hire
Yours, as long as the person who built it stays.

Time to a live agent

Working with me
About three weeks for a focused agent; four to six when it touches many systems.
Agency
Often quoted phase by phase after a paid discovery; ask what counts as live.
Freelancer
Varies; scope drifts without a written spec.
In house hire
Recruiting comes before the first line of code.

Running cost

Working with me
A budget per run, and model usage billed to your own account at cost.
Agency
Often folded into a monthly retainer.
Freelancer
Rarely estimated up front.
In house hire
Visible, plus a full salary whether or not there is work.

Fit check

Is a custom agent the right call?

A good fit when

  • The work arrives as messy text (emails, documents, calls) and needs a judgment call on every case.
  • It touches two or more systems you already use, and someone does it by hand every day.
  • You can point me at real past cases, good and bad, to build the eval set from.
  • You want the code in your hands, free to change it without me.

Not the right call when

  • The steps are identical every time. A workflow is cheaper and more predictable.
  • You want autonomous agents running the business with nobody reviewing what they do.
  • Nobody on your side can approve actions or own the agent after launch.
  • You are still deciding what to automate. Start with the AI Audit instead.

Questions

What people ask before a build starts

Often a workflow or a chatbot is enough, and I will say so. If the steps are the same every time, a deterministic workflow is cheaper to run and easier to test. On a first call I ask five questions to decide which one you need.

Go deeper

Guides and tools on building agents

Tell me the job. I will tell you if it needs an agent.

Three quick questions, and a straight answer on whether it needs an agent.