What Anthropic FDEs Ship
Explore the key deliverables Anthropic FDEs produce in customer engagements, such as production applications, MCP servers, sub-agents, and agent skills. Understand how FDEs define scope under ambiguity, uphold safety and reliability standards, and create reusable patterns that sustain value beyond the engagement.
A platform team at a large retailer asks Anthropic for help putting Claude to work in customer support. The request arrives as a broad goal. The team wants faster answers for its support agents, and it already has a ticketing system, an order database, and internal refund policies that agents apply by hand.
A broad goal gives an engagement direction but no shape. Before the build starts, the FDE turns the goal into a list of concrete things that will exist when the engagement ends. Each item on that list is something the customer can run, inspect, and maintain.
Anthropic’s FDEs deliver a recognizable set of these artifacts, and they build them under clear working expectations. Knowing both lets us describe our own work in the terms an interviewer listens for.
Four artifacts an FDE delivers
An FDE deliverable is a technical artifact that runs in the customer’s production workflow after the engagement ends. Anthropic names four kinds that its FDEs deliver.
Production applications: Systems built with Claude models inside the customer’s own environment and used by real people in daily work.
MCP servers: Services that expose a customer’s tools and data to Claude through the Model Context Protocol (MCP), an open standard for connecting AI applications to external systems. One server can serve any application that supports the protocol.
Sub-agents: Focused agents that a main agent hands a bounded subtask to. Each sub-agent works with its own instructions, tools, and context, then returns its result to the main agent.
Agent skills: Folders of instructions, scripts, and reference files that package a repeatable procedure. Claude loads a skill only when a task calls for it, so a library of skills adds capability without crowding every request.
The four artifacts fit together. The production application is the part users see. MCP servers, sub-agents, and agent skills connect it to the customer’s systems, split its work into focused parts, and encode the customer’s procedures.
For the retailer, the list becomes concrete. The production application is a reply assistant inside the ticketing system. An MCP server gives Claude read access to order status and shipment history. A sub-agent checks each draft refund against policy before a support agent sees it. An agent skill packages the refund policy itself, with its thresholds and exceptions, so the procedure lives in one maintained place.
The image below shows how a customer need becomes a set of delivered artifacts.
Naming the artifacts is the first step. Deciding what to build first usually happens before the customer has answered every question.
Making decisions under ambiguity
The first week of an engagement rarely brings complete information. The retailer may not yet know which agents will pilot the assistant, whether the order database allows read access from a new service, or who approves refunds above a set amount. Autonomy under ambiguity is the practice of making explicit, reversible decisions with the information available, then confirming them as answers arrive. Anthropic expects its FDEs to work this way and to show high agency when the path is unclear.
Four early decisions give the engagement its shape.
Scope boundary: One workflow for one named group, such as refund tickets for the returns team.
Success criterion: A measure the customer agrees to, such as the share of refund drafts that agents send with minor edits.
Integration surface: The specific systems the first version connects to, such as the ticketing system and the order database.
Safety posture: The limits on what the system may read, change, or do during the pilot, such as read-only order access and no refund issued without a support agent’s approval.
These decisions fit on a single page. They set the conditions any technical design must satisfy, and each can change once the customer confirms or corrects it.
Note: Write down unconfirmed constraints
An assumption becomes useful once it is written down, given an owner, and scheduled for confirmation. An assumption kept in one person’s head tends to surface late in the build as a surprise.
The safety posture carries the most lasting weight of the four, because it expresses a standard Anthropic holds every deployment to.
Safety and reliability as delivery standards
Anthropic expects its FDEs to build new solutions while keeping its high standards for safety and reliability. In delivery work, those standards become concrete choices inside each artifact.
Least access: Each MCP server exposes only the tools and fields the workflow needs. The retailer’s server reads order status and leaves payment details out of reach.
Human approval for consequential actions: Actions with real cost, such as issuing a refund, wait for a person to approve them.
Tested behavior before rollout: The team checks the system against real cases, including the awkward ones, before more users depend on it.
Predictable failure: When a lookup fails, or a request is unclear, the system says so and hands the case to a person.
Reliability also depends on people. FDEs work across the customer’s teams and Anthropic’s own, so a limit agreed with the customer’s security team has to reach every engineer building against it. Anthropic looks for a strong cooperation mindset for this reason, and an FDE represents Anthropic in each of those conversations.
Each of these choices takes effort to get right the first time. Capturing them so the next engagement starts from them is the final part of the work.
Turning engagements into reusable patterns
An engagement solves one customer’s problem, and much of what it teaches applies to the next customer. Pattern extraction is the practice of turning a lesson that repeats across engagements into a reusable artifact that another delivery team can start from.
Suppose the retailer engagement shows that every tool connection needs the same agreement. The agreement lists the permitted actions, the required inputs, and a named customer owner. Kept in meeting notes, that agreement helps one customer. Written as a tool contract template, it gives the next team a tested starting point.
Other patterns that often come out of an engagement include the following.
Rollout checklist: Readiness checks, owners, and rollback decisions for moving a pilot to more users.
Evaluation rubric: A scoring guide for judging whether outputs meet the customer’s task and safety needs.
Generalized agent skill: A skill first written for one customer’s procedure, reshaped so other customers with a similar procedure can adapt it.
A good pattern keeps the structure that repeats and leaves the customer-specific details behind. The tool contract template keeps the shape of the agreement, while the retailer’s refund thresholds stay with the retailer.
The quiz below checks how each artifact and practice fits a delivery situation.
Shipping work that outlasts the engagement
The customer’s team keeps running what an FDE builds long after the FDE has moved to the next engagement. The artifacts carry the engagement’s value, and the decisions behind them, about scope, access, and approval, deserve the same care as the code. When we describe our own past work, naming what we shipped, what we decided before the facts were complete, and which limits we held gives an interviewer a clear picture of how we would work inside a customer’s systems. That picture is what the FDE interview loop sets out to find.