What an AI agent actually is
Most software follows a script you wrote in advance. If a customer's request does not match one of the branches you anticipated, the software stops and a person takes over.
An agent works differently. You give it an objective, access to a set of tools, and rules about what it may and may not do. It decides which steps to take, performs them, checks the result, and adjusts. When it hits something outside its remit, it escalates to a human with the context already assembled.
The practical difference is scope. A chatbot answers. An agent finishes. Asking a chatbot about a delivery gets you a paragraph of text; asking an agent gets you the carrier looked up, the customer notified, the CRM updated, and the exception flagged to your ops lead. If you want the underlying mechanics in plain language, the AI agent glossary entry covers them without jargon.
That capability is also the risk. An agent that can act can act wrongly. Which is why the engineering that matters is not the model — everyone has the same models — but the boundaries around it: what it is allowed to touch, what it must confirm, what it must never do alone, and what happens when it is unsure.
Who this is for
Custom agents earn their cost when three things are true at once:
- The work is repetitive but not identical. Pure repetition is a job for a script. Pure judgement is a job for a person. Agents belong in the middle, where the shape repeats but the specifics never do — qualifying a lead, triaging a ticket, chasing a document, preparing a quote.
- The work spans more than one system. The expensive part of most operational work is not thinking, it is carrying information between tools that were never designed to talk.
- Volume is high enough that people are the bottleneck. If a task happens twice a month, leave it alone. If it happens forty times a day and someone is always behind on it, that is the one.
If only one of those is true, you probably do not need an agent — and we will tell you so on the call rather than after the invoice.
What Calfy builds
Every engagement is different, but agents tend to fall into a handful of shapes.
Sales and lead agents
An inbound enquiry arrives — web form, email, marketplace, phone. The agent reads it, enriches it against your CRM and public sources, scores it against the criteria your sales team actually uses, drafts a reply in your tone, books a slot against live calendar availability, and writes the whole interaction back to the CRM as a proper record rather than a note.
What makes this work is not the drafting. It is that the agent knows your qualification rules, your territories, your pricing boundaries, and which enquiries must go to a human immediately.
Support and service agents
The agent handles the tier-one volume end to end: identifying the customer, pulling their order or account history, resolving what it can resolve, and escalating what it cannot with a summary already written. Refunds, address changes, and anything touching money sit behind explicit approval rules.
The measure of a good support agent is not how many tickets it closes. It is how few of the escalations arrive at a human incomplete.
Back-office and operations agents
Document chasing, data reconciliation, status updates across systems, exception handling in a process that mostly runs itself. This is the least glamorous category and usually the highest return, because it is where the invisible hours go.
Research and analysis agents
Monitoring competitors, summarising a regulatory change, assembling a briefing pack before a meeting, pulling a weekly picture out of four systems that each hold a quarter of it. Agents are good at gathering and structuring. They are not good at deciding what it means, so we build these to hand a person a better starting point, not a conclusion.
Internal assistants
An agent your team talks to that has real access — to the knowledge base, the project tracker, the scheduling system. It answers from your own material rather than from the open internet, and it says "I don't know" when your material does not cover the question. That last behaviour is engineered deliberately; models do not do it by default.
How agents fit your stack
An agent is only as useful as its reach. Ours are built to work with what you already run rather than to replace it.
Connection. If a system has an API, we integrate with it. If it does not, there is usually still a way in — a database, a scheduled export, a webhook, an email hook. Legacy systems are normal, not a blocker; most businesses we work with have at least one.
Permissions. Agents get the narrowest access that lets them do the job. Read-only where reading is enough. Scoped credentials rather than an admin account. Every action logged with enough detail to answer "why did it do that" three months later.
Handoff. Every agent has a defined edge. When it reaches that edge it stops and routes to a person, with the context attached. An agent that improvises past its competence is a liability, and confident wrong answers are the failure mode that damages trust fastest.
Evaluation. Before an agent touches production, we test it against your real historical cases and compare its decisions to what actually happened. That is how you find out it misreads a particular account type — while it is still safe to find out.
Monitoring. Once live, it stays instrumented. You see what it handled, what it escalated, where it hesitated. When your business changes, the agent changes with it — that is what "we run what we build" means in practice.
Custom agent or agent-builder platform?
There is a growing shelf of platforms that let you assemble an agent by dragging boxes around a canvas. They are genuinely useful, and for a narrow, self-contained task with a forgiving failure mode, one of them may well be the right call.
They stop being the right call at a predictable point. The first limit is depth of integration: the platform supports the systems it supports, and your unusual one is rarely on the list. The second is control over failure — you generally cannot define exactly what happens at the edges, which matters enormously once the agent touches customers or money. The third is that the logic encoding how your business makes decisions ends up living inside somebody else's product, on their pricing and their roadmap.
A custom build costs more at the start and less over time, and the thing it buys you is that the system belongs to you. Whether that trade is worth making depends on the workflow, and it is a question worth answering before you commit either way.
How the work runs
Four stages, and you know the price before the third one starts.
- Discover. A free 30-minute call, then a proper look at the workflow. We map how the work moves today, where it stalls, and what an agent would actually remove. Sometimes the honest answer is that a simpler automation does the job — workflow automation solves plenty of problems that do not need an agent at all.
- Design. You get a written scope: what the agent will do, what it will explicitly not do, which systems it touches, how success is measured, what it costs, and how long it takes. Clear pricing agreed before any build work starts. Our pricing page explains how engagements are structured.
- Build. Senior engineers build against your real data, not a demo dataset. You see working software weekly. Most agents go live in weeks rather than quarters, and we usually start with the narrowest useful version rather than the full ambition.
- Run. We launch, monitor, and improve. Your team is trained on how to work alongside it and how to override it. The full process is written out step by step.
What we will tell you honestly
Agents are not the right answer to every problem, and the current enthusiasm makes it easy to buy one you do not need.
We will tell you when an off-the-shelf tool covers your case adequately. We will tell you when your data is not in a fit state and needs work first. We will tell you when the process should be fixed before it is automated, because automating a broken workflow just produces broken outcomes faster.
That conversation is free, and it is the same conversation whether or not it ends in a project. See the full range of services if you are still working out which shape your problem is.