AI Agents & Automation

What AI Agents Actually Are

An AI agent is a piece of software that uses a language model to make decisions and take actions — not just answer questions. The difference matters. A chatbot answers. An agent does things: it reads data from your CRM, sends an email, updates a record, calls an API, generates a report, and then moves on to the next task without someone pressing a button for each step. This shift from "AI that responds" to "AI that acts" is what makes agents genuinely useful in a business context rather than just impressive in a demo.

The agent pattern has become practical in the last couple of years because language models have gotten good enough at reasoning and function calling that you can give them a goal, a set of tools, and constraints on how to use those tools, and they'll figure out a reasonable sequence of steps to reach the goal. They're not perfect — they make mistakes, they need guardrails, and they need to be monitored — but for the right tasks, they can handle work that previously required a human making decisions at every step.

The Kinds of Work Agents Are Good At

Agents work best for tasks that are repetitive, involve gathering information from multiple places, require making decisions based on a defined set of rules, and don't need creative judgment at every step. Sales development is a good example: research a prospect, check if they fit your ideal customer profile, draft a personalised outreach email based on their company and role, log the activity in the CRM, and move to the next one. A human could do this, but it's tedious, and the AI can do it at a scale no individual person could match.

Customer support is another strong use case. Not replacing human support entirely — but handling the tier-one queries that account for 60-70% of volume: order status, account questions, password resets, common troubleshooting steps. If the agent can resolve those automatically by checking your systems and responding with accurate information, your support team can focus on the genuinely complex cases that actually require human judgment.

Internal operations is a third area: automatically categorising and routing incoming requests, generating weekly reports from your analytics data, monitoring systems and alerting on anomalies, processing documents and extracting structured data from unstructured inputs. These are tasks that are currently either not being done or being done manually by someone who'd rather be doing something more valuable.

How We Build Agents

The foundation of most agents we build is a language model with tool-calling capability — the model can invoke functions we define, like "look up customer record", "send email", "create CRM note", or "query database". The model decides which tools to call and in what order based on the goal it's been given. We define the tools, the model orchestrates the execution.

For more complex workflows — agents that need to maintain state across multiple steps, agents that spin up sub-agents for specific tasks, or agents that need to handle branching logic — we use LangChain or LangGraph to structure the agent's behavior. These frameworks give us control over the execution flow while still letting the model handle the reasoning and decision-making parts.

For agents that need to work with your specific data — internal documentation, product knowledge base, customer history — we set up retrieval-augmented generation (RAG). This means your data is indexed in a vector database (Pinecone, pgvector, or Qdrant depending on your stack), and when the agent needs relevant context, it retrieves the most relevant chunks before generating a response. This is what allows agents to answer questions accurately about your specific domain rather than making things up.

Integration Is Where the Value Is

An agent that can only access a language model is useful for generating text. An agent that's connected to your actual systems is useful for doing work. The integration layer is where most of the engineering effort goes — and where most of the value comes from.

We connect agents to the tools your team uses: Salesforce and HubSpot for CRM operations, Slack and email for communications, Google Workspace and Notion for documents and notes, your own internal APIs for product-specific operations, databases for reading and writing data. Every integration is built with appropriate permissions — the agent can do what it needs to do and nothing more.

We also build in the logging and audit trail that makes enterprise use of agents practical. Every action the agent takes is logged with the reasoning that led to it, the inputs it received, and the output it produced. This serves two purposes: it lets you debug problems when something goes wrong, and it lets you demonstrate to stakeholders (or regulators) what the agent actually did and why.

Guardrails and Safety

Giving software the ability to take actions in the real world — send emails, update records, spend budget — requires careful thinking about what happens when it does something wrong. Language models are not deterministic; they can misinterpret instructions, get into unexpected states, or make judgment calls you didn't intend. This isn't a reason not to use them — it's a reason to build proper guardrails.

We implement human-in-the-loop checkpoints for any action with significant consequences. Before the agent sends a cold email to a prospect, it drafts it and waits for approval. Before it makes a change to customer data, it shows the change and asks for confirmation. The threshold for what requires approval versus what can be done automatically is something we define with you based on your risk tolerance and the specific task.

We also implement confidence thresholds and fallback behaviors. If the agent isn't confident about how to handle a situation, it escalates to a human rather than guessing. If a tool call fails, it handles the failure gracefully rather than continuing with incomplete information. These aren't just nice-to-haves — they're what makes agents reliable in production rather than reliable only in demos.

Model Selection and Cost

Different tasks call for different models. GPT-4o and Claude Sonnet are powerful and handle complex reasoning well, but they cost more and are slower than smaller models. For high-volume tasks where the reasoning is relatively simple — categorising support tickets, extracting structured data from documents — a smaller, faster, cheaper model often works just as well. We evaluate the right model for each use case rather than defaulting to the most capable (and most expensive) option for everything.

Cost management matters more than most people realize when they're building their first AI product. At low volumes it's negligible. At scale — processing thousands of documents, handling thousands of support conversations — model costs become a real line item. We build with cost awareness, measuring tokens per operation and projecting costs at scale before you're committed to an approach that's expensive to change.

Building Vs. Buying

There are SaaS products that provide pre-built agent functionality — Zapier, Make, and various AI-specific automation tools. For simple, well-defined workflows these can be the right answer. We're honest about this when it applies to your use case. Where building custom agents is the right choice is when your workflow is complex enough that no off-the-shelf tool handles it, when you need tight integration with proprietary systems, when you need the agent to have deep knowledge of your specific domain, or when the cost of SaaS tools at your scale exceeds the cost of building it yourself.

Reliability in Production

A common problem with AI-powered systems is that they work well in development and become unpredictable in production. This happens for a few reasons: edge cases in real data that didn't appear in testing, model outputs that vary slightly between runs in ways that matter, external APIs that the agent depends on having occasional downtime, and context windows that overflow in ways not anticipated during development.

We test agents against representative samples of real data before going live. We build retry logic and fallback behaviors for external dependencies. We set up monitoring that tracks not just whether the agent ran, but whether it produced the right kind of output. We tune prompts against real examples rather than synthetic test cases. Production readiness for an AI system requires more than the usual definition of "it works in testing".

Frequently Asked Questions

Which model should we use — OpenAI or Anthropic? Both are excellent and we work with either. The choice depends on specific capabilities your use case needs, your existing infrastructure, and sometimes just preference. We evaluate both for any new project and make a recommendation based on what we find.

How long does it take to build an AI agent? A focused, well-scoped agent for a specific workflow typically takes four to eight weeks including integration work, testing against real data, and the iteration that always comes from seeing it run on actual inputs. More complex systems take longer.

What does it cost to run AI agents? It depends heavily on the volume of work and the models used. We model out the costs as part of the scoping process so there are no surprises. For many workflows the cost per operation is measured in fractions of a cent, and the value of automating the work is an order of magnitude larger.

Can agents fully replace human workers? For specific, well-defined tasks — yes, often. For anything requiring genuine judgment, creativity, relationship management, or handling of genuinely novel situations — no. The best implementations use agents to handle the volume work so humans can focus on the things that actually require a human.

Getting Started

The best first step is identifying the specific workflow you want to automate — one concrete process with clear inputs and outputs, not a general goal of "using AI more". From there we can evaluate whether an agent is the right solution, estimate the effort and cost, and design the architecture. Most good agent projects start narrowly and expand as you see what works.