Agents that do the work, not just describe it.

A chatbot answers. An agent acts. A chatbot takes a question and returns text, and the person still does the work. An agent is given a goal and a set of tools — your CRM, your database, an email API, a payment system — and decides which to call, in what order, reacting to what each one returns until the goal is met or it hits a boundary you set. The practical difference is what happens after the conversation: a chatbot leaves you with an answer to act on, an agent leaves you with the thing already done and a log of how. Agents are correspondingly more serious to build, because a system that can take actions can take wrong ones.

By constraining what it is able to do rather than relying on asking it nicely. Four things do most of the work. The agent only gets tools it genuinely needs, each scoped to the narrowest permission that works — an agent that never needs to delete records has no delete tool. Outputs are validated against a schema before anything downstream acts on them. Anything hard to reverse — sending to a customer, moving money, deleting data — goes through a human approval step by default. And every run is traced, so when something is wrong you can see exactly which step caused it instead of guessing. We agree which actions require approval during scoping, and that list is part of the written scope.

Four things, in roughly this order of impact. First, how many times it runs — an agent triggered per customer enquiry costs proportionally more than one that runs nightly. Second, which model each step uses: a well-designed agent routes simple steps to a small fast model and reserves the expensive one for genuine reasoning, which is frequently the difference between a comfortable bill and an alarming one. Third, how much context each call carries, which is why retrieval quality matters commercially and not just technically. Fourth, hosting, which for most agents is minor next to model usage. We design for this from the start, and you hold the model account directly so you see real usage rather than a marked-up line on our invoice.

Not under the standard API terms of the major providers. Anthropic and OpenAI both state that data submitted through their APIs is not used to train their models by default — this differs from their consumer chat products, which is the source of most confusion on this point. Beyond that, the architecture matters: agents are deployed into your own cloud account with your own model keys, so your data path is yours and you can audit it. Where data is genuinely sensitive we can restrict what ever leaves your infrastructure, keep retrieval local, or use a self-hosted open-weight model. If you are under GDPR, HIPAA, or a client contract with data terms, tell us during scoping and it shapes the design.

Both are treated as expected conditions rather than edge cases, because at sufficient volume both will happen. Agent state is persisted at each step — this is a large part of why we build on LangGraph — so a run that fails partway can resume from the last good step instead of starting over or, worse, repeating an action it already took. Calls retry with backoff, and where it makes sense the agent falls back to a second provider. Actions that must not happen twice are made idempotent. And there is always a defined degraded path: what the system does when the AI is simply unavailable, which for most business processes should be to queue the work and alert a human rather than fail silently.

That is usually the entire point. If a system has an API, an agent can use it — CRMs, helpdesks, spreadsheets, calendars, accounting, WhatsApp, internal databases. Where a modern integration exists we prefer it, including MCP servers where a vendor provides one, because it keeps the tool layer swappable rather than hardcoded. For systems with no API, options narrow to scraping, file exchange, or database access, and each carries a fragility we will name honestly before you commit. The integration list is agreed in writing during scoping, since it is also the single largest driver of build cost.