Questions, answered

An AI agent is a scoped autonomous worker: it owns one job, uses tools and data to do it, and escalates what it cannot finish. The three parts that make it an agent rather than a model are the tools it may call, the memory of what it has already done, and the written limit on what it may do alone. Longer version: what is an AI agent.

Rule-based automation follows a path someone drew in advance and stops at the first thing that path did not anticipate. An agent reads the situation, decides which step applies, and handles inputs nobody scripted. The practical difference shows up in exceptions: scripted automation hands you every case it did not expect, an agent handles most of them and hands you the residue with its reasoning attached.

Work that is high-volume, rule-shaped, text- or data-heavy, and reversible. Triage, matching, extraction, research, drafting, reconciliation, first-line support and routine engineering chores all sit in that space. What it does badly is anything turning on relationship, negotiation or accountability to another person, and anything where the correct answer is not knowable from the data available.

Usually a few, each owning one job, coordinated by an orchestration layer. One large agent that does everything is harder to test, harder to bound and harder to debug, because a single failure could have come from any part of it. A narrow agent has a pass rate you can measure and a boundary you can write down. Browse the 24 agents to see the granularity we mean.

It is set by scope rather than by seats: how many processes, how many systems each touches, how many exception types it carries, and whether you operate it or we do. We publish the shapes and the drivers rather than a price list, because a figure without your process behind it would be decoration. The three engagement shapes has the detail.

Model calls, compute and storage, billed to you by your providers at cost, plus operation if we do that. We do not resell inference at a margin. Running cost falls over time when a cheaper model clears the eval bar, and that fall shows in your monthly report rather than staying with us.

By modeling it before you commit, then measuring it after. The ROI calculator turns volume, minutes per task and routine share into hours returned, and lists five costs it deliberately does not count. The readiness audit then replaces the guessed routine share with a measured one. If the case only works with optimistic assumptions, it does not work. Background reading: how to model agent cost.

Yes, and it is the thing we recommend most often. The readiness audit is fixed-scope, runs in days rather than months, and is designed to be able to tell you not to proceed. Plenty of engagements should end there, and the report is written so another vendor could act on it.

Typically under 30 days from the start of the audit to an agent working on a narrow task in production, and 3-6 months for a broad process spanning several systems. What moves the number is data access, system count and exception density. The audit gives you your own figure instead of this one.

Because most of the first build is the layer underneath: retrieval, the tool gateway, evals, observability and the audit trail. The second agent reuses all of it and needs only its own tools, data and boundary. This is also why "add one more agent" is a quarterly conversation rather than a project.

Access approvals, by a wide margin. Engineering work is estimable; waiting six weeks for a credential is not. Second is the absence of a process owner with a few hours a week to answer questions, which is the single largest predictor of whether a build lands on time. The seven stages lists what each one asks of your team.

That is exactly the shape of the first three stages. The audit decides whether to build, the blueprint decides what, and the prototype proves it on your real data with accuracy, latency and cost measured. There is a gate after each, and stopping at one is a normal outcome rather than a failed engagement.

A written autonomy boundary, enforced outside the model. Permissions live in the tool gateway, so an agent cannot exceed them by being persuaded through its prompt. Anything irreversible sits behind an approval gate with a named person, and there is a kill switch that stops one agent or all of them without a deployment. The full control set.

No. We contract for zero training rights with every provider we use, and we prefer architectures where your data does not leave your tenancy. Retrieval indexes are built inside the boundary you choose, permissions from the source system are carried through, and every read is logged.

It is caught, logged, and either repaired or handed to a person. Known failure classes get a known fix and a retry. New ones stop the agent, raise an alert with the full trace, and route the work to someone rather than leaving it queued behind a broken step. Every action is reconstructable months later from its audit entry.

No, and we will not imply otherwise. We hold no SOC 2, ISO 27001 or equivalent attestation today. The control set an auditor would examine is in place and described in full on the governance page, but the third-party attestation does not exist yet. If your procurement requires one, we are not the right supplier yet.

If it has an API, an agent can use it. If it does not, we build the bridge, and that bridge is scoped and priced like any other integration rather than waved at. What matters more than the name of the system is how many of them are involved, because each one brings its own authentication, rate limits and failure modes.

No, and most clients do not have one. You need a process owner who knows how the process genuinely runs, someone who can approve credentials, and a reviewer during rollout. If nobody wants to watch evals in month four, the managed option exists for exactly that reason.

Common, and a good place to start. We assess what exists against evals rather than impressions and tell you what to keep. The fix is often retrieval, sometimes orchestration, sometimes a smaller model and a tighter boundary. We will also say when a rebuild is cheaper than a rescue. All 19 services covers both paths.

That is your decision, not the model's, and any vendor who answers it for you is selling. What we can say is what the work looks like afterward: the routine share stops reaching a person, and what is left is the exceptions, the judgment calls and the customers. Teams that plan for that keep their people. Teams that do not, do not.

You do. The agents, their configuration, the eval suites, the runbooks and the audit history are yours whether or not we keep operating them, and the runbooks are written for a reader who is not us. Handover is a stage in the process rather than a negotiation at the end of one.

Yes, and it is the usual shape once a build starts. Your engineers know the systems, the failure modes and the internal politics of an integration. We tend to own the agent design, the orchestration layer and the evals, and hand those over progressively if you want them.

Then that is the recommendation, in writing, with the reasoning. It has happened and it will happen again. An assessment that can only ever recommend a build is a sales call with a document attached, and it is the reason we keep the audit small and fixed-fee.

One process, described in a sentence: what happens today, who does it, and how often. That is enough for a first read on feasibility. Book a discovery call and you will spend thirty minutes with the person who would design the build.