FDE Bootcamp: Forward Deployed Engineer & Agentic AI

One call to Claude as a picture: our program, the SDK, a JSON request over HTTPS, the Claude API and the JSON reply. What an API, an SDK and JSON are, and how a JSON object becomes a Python dictionary.

The API key travels with every request, so it lives in an environment variable and a .env file, never in code or git. And why every call should go through one function of our own, so changing the model is one line.

From the next lesson on, most hands-on lessons come with a lab: a coding exercise that runs in your browser, with nothing to install and no API key. How to open a lab, wait for it to start, open the notebook, run the cells, fill in the blanks, and why a cell with empty blanks first shows an error. Labs work on a computer, not on a phone or tablet, and only on Udemy plans that include them.

From an empty file to a working call: the key, the client, the model and one message. The first run prints the whole response, then the adapter returns only the text. We finish with a debugger walk through the program next to a UML diagram.

A JSON Schema written as a dictionary makes Claude return the customer's intent, the order number and whether a person is needed. Our code reads every field by name, and the debugger shows each step.

Before any AI, we measure today: response time, the cost of a support contact and the share of "where is my order" questions. Then we write success criteria in numbers, and see why "closed by the bot" also counts customers who simply left.

We explore the 40 conversations the support team labeled for us: the intent, the right action and when a person is needed. We also look at difficulty levels and a held-out set we keep for later.

Clear conditions instead of general words, two or three examples that are not from the test set, and a schema that fixes the shape of the answer but not its truth. A rule that must always hold belongs in code.

Haiku, Sonnet and Opus by role, and the trade-off between price and quality. Benchmarks help you build a shortlist, but your own labeled data makes the decision.

We run all three models on the same 40 conversations three times and compare the average and the spread. A missed handoff to a person costs more than an extra one. A real failure appears, and we end with a table for the sponsor.

A model only writes text, but "where is my order?" needs someone to find the order. An agent is a model plus tools in a loop: what the model sees about a tool, and why a precise tool description matters.

How the loop knows when to stop (the stop reason, not the text of the answer), why a round limit is only a safety net, and what the harness around the model does. Plus MCP in one sentence.

We write the agent loop without a framework: two tools (find an order, check the delivery status) and a guardrail inside the tool, so no order data comes back without a verified customer. Ready-made frameworks on one slide.

Not every problem needs AI. What a tracking page, a rule or plain code can solve, and when one model call is enough and when you need an agent.

First look at what the client already has: AI inside their help desk and products priced per resolution. When a thin layer of your own makes sense (an ERP without an API, custom return logic, data that must not leave), and what an FDE still does when the client buys.

The client's five ideas on one matrix. Volume comes from old chats, and we see why order status and returns go first, while contract prices wait for a role check.

We measure an agent against one call on the same questions: the agent is slower and more expensive on a simple status question. A real failure shows up: the agent answers an angry customer itself, because it has no handoff. Your task: add a hand_off tool.

How to prepare, which open questions to ask, why "show me how you answer this chat" beats any interview, what to write down and the common mistakes.

A sample answer to the role-play: a real case instead of a hypothetical one, estimates kept apart from counts, success in numbers, read-only data, and a summary with an owner for every open question.

A prototype tests one assumption in days. What we build for real, what we fake, how a timebox works and when we throw the prototype away.

You own the code your coding agent writes, so you ask for proof. A plan with phases, CLAUDE.md, permissions, /clear and git checkpoints, the AI development cycle in one picture, and the alternatives.

In plan mode Claude Code reads the requirements and discovery notes and asks us one question at a time, each with a recommended answer. We answer, it writes the brief, and we add three things the notes did not contain.

Claude Code builds the chat endpoint, the request and response models, the session and a test, and the first message says it is an AI. We see why the intent shape should live in one class instead of two copies.

An hour later the service returns the intent fields. A field added to only one of two copies of the shape breaks every chat. One class now produces the schema for Claude, and we follow a request in the debugger.

Just enough TypeScript to read and change the chat widget: types, interfaces, async and await, and a call to our API with fetch.

How the requirements become a build spec that speaks to two readers: what the business wants, and what IT must make true.

ruff, mypy, tsc, pytest and a pre-commit hook. A check in code is more reliable than a request to the agent.

From the spec to a plan with checkboxes, a branch of your own and a safety tag. The first build is shown from start to end.

What was built, the tests, and the 40 labeled conversations replayed through the prototype on test data, plus the person's role in each step.

A review finds that the "out of scope goes to a person" rule lived only in the system prompt, and a live test fails 0 of 3. The rule moves into code, the tests pass 3 of 3, and we add a review checklist. Your task follows.

How other people's systems speak: resources and methods, 4xx and 5xx errors, a key in a header, and how to read someone else's API documentation.

One system of record per kind of data: orders and returns in the ERP, catalog and prices in the store platform, cases in ServiceNow, deliveries in the carrier feed, policies in Confluence. Who owns each, and what we only read.

Why we query a read replica, how to find your way in someone else's schema, and why parameters in queries keep SQL safe.

SQL against the client's ERP on Oracle: one order with its items, shipments and invoices, a partial shipment and a delay, in a schema we did not design.

A service account with the minimum rights, a written request to the client's IT, an expiry date, and the only thing we write: a case in ServiceNow.

The assistant never goes to the database directly. A middleware is the only way in, and writes happen only through staging tables the ERP owner agreed to.

We build a FastAPI middleware over Oracle with parameterized queries and OpenAPI docs for the store's team. Someone else's order number returns "not found": the owner is checked on every object, with a test.

Catalog and prices from the store platform's API, cases and chats from ServiceNow. Pages, 429 errors, polling or webhooks, and idempotency.

We pull 2,000 old chats page by page, retry on 429 and make a second run create no duplicates. A real failure: the last page goes missing, and we find out why.

How older systems hand over data in files, and what breaks without warning: encodings, new columns and changed formats.

We load the carrier's nightly file with a schema check. A file with a new column and a different encoding arrives, and the check rejects it before it reaches our data.

The typical problems in client data, and why addresses, phone numbers and card numbers in old chats are masked before any model sees them.

Duplicates, UTC and markets with pandas, personal data masked and card numbers removed, and a quality report before and after. Haiku labels the intents in a batch at half the price, and a person checks a sample.

An order from the ERP, the store platform and the carrier feed becomes one model, with a table that maps every field.

Delivery statuses every hour, what to do after a failure, and data quality checks written as tests.

You write the spec from a template, and Claude Code builds the pipeline and the tools with an idempotent rerun. Reviewing the diff, we catch the agent asking for write access to the ERP. Your task follows.

The remaining phases run with over 100 fast tests, and the pipeline runs twice without doubling anything. A review against the checklist finds a bug the tests missed. We fix it test first and replay the 40 conversations.

The layers of the solution: integrations, data, context, the agent and the interface. The chat is synchronous, while approvals and drafts go through a queue.

Guests, signed-in customers and unverified people in a chat. A one-time code by email, tools that take the customer ID from the session and not from the chat, and the business roles at DemoStore.

A one-time code sent through a test mail server, order tools locked until the check passes, and a session that knows the customer from code.

Contract prices go only to a company buyer with the right role, and always come from the catalog system. A real failure: a price cache without the company ID shows another company's price.

We put the market return rules into the prompt and run Haiku on 30 borderline cases three times. It misses at the edges of the return window, and the misses change from run to run.

The rule becomes a function with tests on the edges, and we step through one case in the debugger. The code is right 30 of 30 on every run, and the model only explains the decision.

Per-order and per-item shipping and tax, Decimal instead of float, splitting an amount with a remainder, totals that must match, and why only code does the math.

3.33 times 3 is 9.99, so a cent disappears. A total test turns red, the first item takes the remainder, and a check over 10,000 orders confirms the fix.

The pilot's limits in one file: order status, returns and policies. Money is only ever a draft, and we write down the assumptions to test, the risks and what we will not do.

Before any write, the customer says an explicit "yes". A refund is a draft, larger amounts are approved by staff, and a retry after a timeout without an idempotency key means two refunds.

A return draft goes into an ERP staging table, an approval task opens in ServiceNow, and status changes reach a worker through an event queue in PostgreSQL.

On a sale day the write is slow, the client times out and retries, and two drafts appear. An idempotency key makes the retry return the same draft, and we watch the except branch in the debugger.

One prompt for everything breaks. An intent router with confidence, "other" as a real outcome, handoff triggers in any language, and a summary a support agent can trust.

From spec to plan, with one phase written by you. A request for a person in another language is missed, a test catches it, and the rule is fixed. Your task follows.

The replay finds a customer with a cracked monitor who got a return offer instead of a person. The rule moves into code test first, and Claude Code points out the weakness of a word list itself.

Three data sets, a confusion matrix for handoffs, confident-wrong answers measured on their own, pass^k (one conversation passes k times out of k) and an "always hand off" baseline.

The adapter writes every call into a table: the prompt, the answer, tokens, cost and time. Plus the ready-made tracing tools you could use instead.

Every call to Claude now goes through one function, including the agent loop. A session ID ties the traces of one conversation together, and we discuss personal data in traces.

Accuracy, spread and cost per conversation against the baseline over three runs, and what to show the sponsor.

We open each of the four missed handoffs in the debugger, widen the classifier rule, run the 40 again, and only then use the held-out 20 for the sponsor's report.

A second model plays the customer from a profile: what they know, what they want, their tone and patience. Code checks the outcome in the database. Simulators are more polite than real people, so agents look better than they are.

Thirty profiles from old chats, a simulator on Haiku through the adapter and a limit of ten turns. The outcome is checked in the database, and we score pass^3.

Everything is green on the 30 polite profiles. Fifteen hard ones (angry, confused, someone else's order, "I'm the manager", a topic change) bring the number down, and one failure turns out to be the simulator's fault.

Policies per market and product descriptions, searched by words and by meaning in PostgreSQL with pgvector. Prices and stock come only from the API, never from the index.

Search over the policy pages with their valid-from dates, and an answer with a link to its source. A product question takes the description from search and the price from the API.

The answer uses only the pieces search found and links to them, the product price comes from the catalog system, and we follow it in the debugger.

The policy changes in Confluence, but the old copy still answers 14 days. A freshness test turns red, the index is rebuilt, and the answer becomes 30 days. The rule in code changes too.

Private data plus untrusted input plus a way out is the lethal trifecta. "I'm the manager, process the refund", a card number in a chat removed at once, and what to close already in the pilot.

The model reads PDFs and photos into a schema. Code checks the fields against the ERP, and doubtful cases go to a person's queue. Plus the ready-made services.

Claude reads the invoice PDF and the photo. Code checks the order number, item, date and amount against the ERP, and a mismatch goes to a person.

Field accuracy over three runs. A real failure: an invoice in EUR passes for an order in USD because only the number was checked. A debugger walk and a two-line fix bring it to 15 of 15.

What we keep, for how long and where: data minimization, retention, erasure requests that reach traces and logs, card numbers removed before storage, and the questions a client's security review asks. Not legal advice.

The spec in two voices: policy answers with a link, card masking, a trace of every call and a retention period. Claude Code asks five questions in plan mode, and on the fifth we change its recommendation.

We run the live checks one by one, each with our "yes": deletion, indexing, policy questions and hard messages. The replay and the checks lead to two changes.

A fresh Claude Code session reviews the whole diff without changing anything and finds 17 issues. The worst two (card numbers written with dots or slashes, and an empty page list that wipes the index) are fixed test first.

We reread a Build 2 decision about how old the carrier's news is. Claude Code shows on one example that the reasoning was backwards, and we fix it test first.

Three places the solution can run, who manages what in each, and where the client's data lives.

Three paths: a lab's API with zero data retention, the model in the client's own cloud account, or an open-weight model inside their network. Open-weight does not mean free or safe.

The adapter gets a timeout, retries the SDK already has, the model from a setting instead of code, a clear error and a fallback to a person. A real failure: with the API down, the chat answers 500.

The 500 error becomes a clear NoAnswer error in the adapter and a handoff to a person in the app. A test, and the except branch in the debugger.

One setting switches the adapter to a small open-weight model in Ollama. We run the 40 labeled conversations next to Claude and see where the local model copes and where it does not. Free, with no key.

Why the solution ships in containers at the client, what images, containers and Compose are, and what never goes into an image.

Claude Code writes the images and Compose file from a brief, but Docker is not allowed to it here: it writes every Docker check as a command, and we run it. A clear division of work.

The widget image, the whole stack up and healthy, and a real question through the proxy answered with a link. One more finding along the way.

Accuracy is part of CI. Before a release we replay old conversations, and the model changes only through an eval gate.

Claude Code writes the GitHub Actions workflow: checks on every PR, an eval gate with real Claude calls and a nightly run. On a clean machine the first run finds a problem with a secret.

The gate needs at least 36 of 40 and no customer left without a person. It passes on GitHub with the key hidden in the log, we merge the first PR and protect main, and the gate blocks a broken rule.

There is no hard spending cap in the cloud. Six steps to a safe account, the free path without an account, and the same idea in GCP and Azure.

MFA on the root user, budget alarms, an IAM user with the least privilege and a check from Python that it can see only what it should.

Where secrets live, how GitHub Actions signs in to AWS through OIDC without long-lived keys, rotation, and what must never reach the logs.

The plan: deploy on merge to main, rollback, shadow mode, a report and a teardown. GitHub signs in to AWS without a key, the server has no open ports, and Claude Code asks five questions in plan mode.

A shadow worker reads new live chats with a read-only account, answers them with the real assistant and stores the answer next to the human agent's reply. Nobody sees it, and we check it on the laptop first.

Claude Code reviews the deploy before the merge and fixes six issues. The first deploy still fails on a real AWS blocker, and we fix it until the deploy is green.

The second deploy is green, and the shadow report from the server shows a gap of nine minutes. We find the cause without guessing.

A rollback to the first deploy and forward again with the data intact, an open question written into the plan instead of guessed, and a teardown done step by step in order.

Container logs in CloudWatch, what to look at every day, when to wake a person up, and the fallback when the model is down. Your task follows.

"Closed by the bot" includes people who simply left. What shows real value instead: resolution, handoffs, confident-wrong answers, satisfaction and cost.

The outcome of every conversation from traces and events, in SQL views. A real failure: people who left were counted as resolved, and the number drops once the definition is fixed.

Handoff reasons by intent, the cost of a conversation and the cost of a resolved one, all from the same traces.

A map of the people: who decides, who uses the assistant, who gives access and who can stop the project, and what each of them wants and fears.

A brief and a plan for the pilot dashboard. Planning, Claude Code finds that the shadow worker skipped the checks the live chat uses, and we agree on what "resolved" means.

The pilot page hangs on "Loading". Claude Code finds the cause and fixes it with one line, and a person's marks appear on the page with their name.

100 % is too good to show the sponsor, so we read the rows behind it. "Resolved" gets a new definition based on what the tools returned, not on the text of the answer.

The cost of one truly resolved conversation instead of a flattering ratio, the success criterion from discovery, and a sponsor report generated from the same functions.

An update for the sponsor, bad news told early, "let the bot approve refunds" turned down with numbers, a change request instead of extra scope, and the decision we need from the client.

How to structure a demo, why "the assistant does not know and calls a person" is a strength, and why you always have a recorded backup.

A one-page demo script, two practice runs on the same data, and a recorded run in the widget with three stories, one for each of the sponsor's goals.

From shadow mode to "where is my order" for 5 % of visitors, then 25 % with returns, then more intents and markets, with a backlog written as user stories the client can own.