Forward deployed engineering for AI agents

Most embedded engagements now involve an agent. This page is about what that specifically requires.

Why agents pull this role

An agent that answers questions is an integration. An agent that takes actions is an organisational change, and the difference is where the work goes.

An acting agent needs to know what it is allowed to do, on whose behalf, with what data, and what happens when it is unsure. Every one of those four is a property of the customer's company rather than of your product. You cannot design them from a discovery call, because the answers do not exist yet in a form anybody has written down.

The hiring data reflects this. Across 1,000 postings, AI agents were named in 35 percent, LLM experience in 31 percent and retrieval in 12 percent. Agent work is now the modal engagement rather than an emerging one.

Permissions are the hardest part

This is the finding that surprises teams, and we have written about it separately because it comes up so often: permissions are the hardest part of an AI feature.

The problem is that the business treats roles as different in ways the software does not model. A claims handler and a senior claims handler have different authority in practice, encoded in a habit rather than a permission. An agent acting on behalf of the first must not do the things only the second may do, and nobody has ever had to write that distinction down because humans just knew.

An embedded engineer finds this in week one by trying to ship something small against real data. From outside, it appears in month four as a security review objection nobody anticipated.

The pattern to insist on. The agent inherits the permissions of the person it acts for, rather than running on a broad service account. Palantir's AI FDE documentation describes exactly this for its own agent: all operations respect existing user permissions, with context starting minimal and expanding as the user chooses. A wide service account is the easy default and it is how a helpful agent becomes a breach. Security and access covers it.

Tool access is a scoping decision, not a config

Every tool you give an agent is a capability and a liability. The decision of which tools it gets is a business decision dressed as a technical one, and it needs the customer in the room.

Two questions per tool. What is the worst thing this could do if the agent is wrong? And is that acceptable without a human in between?

For read-only tools the answer is usually yes. For anything that writes, moves money, contacts a customer, or changes a record somebody relies on, the answer is usually a review step. Our post on deciding if a feature needs a human in the loop covers the judgment.

The escalation path is most of the design

For an agent in production, the interesting design work is not the happy path. It is what happens when the agent is unsure or wrong.

What triggers escalation. A confidence threshold is the crude version and it is rarely sufficient. Better triggers are usually structural: this action type always escalates, this value threshold always escalates, this customer segment always escalates.

Who receives it. A named role, with capacity. An escalation queue nobody owns is a queue that grows.

What they see. Enough context to decide quickly, which usually means the agent's reasoning and the underlying record rather than just its conclusion.

What the end user sees. Whether they know an agent was involved, and what they can do about it.

Getting these four wrong is the most common reason an agent gets switched off after launch, and none of the four can be answered without the people who will operate it.

AWS's framing, which is the right order

The AWS partner programme names a methodology, Agentic Process Transformation, which directs customers to start with a business process, reimagine it for the agentic world, deploy it into production, and demonstrate measurable results.

Starting from the business process rather than from the capability is the correct order and the opposite of what most agent projects do. The common failure is starting from what the model can do and looking for somewhere to apply it, which produces a capable system attached to a process nobody needed changed.

Anthropic's own posting for the role names delivering technical artifacts such as MCP servers and agents for production use, which tells you the concrete deliverable shape this work now takes.

Verification, which agents make harder

An agent's output space is larger than a normal feature's, so the checks have to be different.

Testing an agent against a fixed set of expected outputs breaks quickly, because there are many acceptable answers. What works is evaluating properties: did it stay inside its permissions, did it escalate when it should have, did it avoid the actions it must never take, is the outcome within tolerance.

Those checks come from the specification, before the agent exists, and they are graded by something other than the model being tested. Eval-driven development is the method, AI agents in production covers the agent-specific version, and never letting the model grade its own work is the rule that makes the grading meaningful.

This is also the handover artefact. A customer team inheriting an agent needs the eval suite more than it needs the code, because the code will change and the suite is what tells them whether the change was safe.

What to ask before starting an agent engagement

Who does the agent act on behalf of, and does your permission model represent that distinction today? What is the worst action it could take, and is that acceptable without review? Who receives escalations, and do they have capacity? And what business process are we changing, rather than what capability are we deploying?

Four questions. If the answers do not exist, that is the first phase of the work rather than a reason to delay it.