How FDE actually works

01The demo isn’t the job

Last week I wrote that the model is the easy part.

A few people asked the obvious follow-up: then what’s the hard part?

Here’s my answer. Forward-deployed engineering, FDE, is four steps: audit, redesign, evals, deploy. That’s it.

The words are simple. The work isn’t. So in this letter I’ll show what each step actually means, using the one business I know inside out: Байр 3, the rental building I manage.

All tenant data here is made up. The workflows are real.

Four steps. Skip one and the other three don’t hold.

02The promise: a K, not a line

Before AI, the operation runs on one line. More units means more work, more checking, more people. Value per person stays flat.

After the work is redesigned, the line splits into a K.

The top arm goes up: units run and income per person. The bottom arm goes down: cost per task. The space between them is the gap you’re paying an FDE to open.

Look at what sits at the split. Not a model. Not a tool. The method: audit, redesign, evals, deploy.

The vertical line through that point divides two ways of operating. On the left, the pre-AI process. On the right, the post-AI operation. Same tenant journey underneath. Very different work on top of it.

There are no numbers on this chart. I don’t have before-and-after figures for my building yet, and I won’t make them up. The shape is the claim. The numbers come once it’s measured.

The K doesn’t come from the model. It comes from the method.

03Step 1: Audit. Map the work people really do

Here’s the tenant journey at Байр 3: inquire, qualify, sign, move in, pay rent, remind, maintain, move out.

Above and below that line sit the people doing the work. Me, staff, the workers who fix things. Under each one, a column of tasks.

Before, every task looks the same. A grey dot. Someone checks criteria. Someone re-types the lease into the sheet. Someone writes paper notes at handover. Someone matches bank transfers by hand. Someone rechecks every balance before a reminder goes out. Someone works out a refund from memory.

That’s what most businesses look like from the inside. Not broken. Just held together by people.

An audit makes that visible. You don’t ask, “where can we use AI?” You ask, “what actually happens here, step by step, including the exceptions?”

The exceptions are where it gets interesting.

The documented process vs what actually happens

Take daily rent reconciliation. On paper it’s six steps:

1. Read the bank statement
2. Match each payment to a unit
3. Split rent from utilities
4. Update the sheet
5. Produce the rental report
6. Send SMS reminders

Clean. Anyone could follow it.

Now here’s what actually happens, from my own books. Those six steps turn into eighteen.

• A payment has no unit in the reference. No unit number, no name, no phone. So I get asked, then the match runs again.
• Rent and utilities arrive in one transfer. Two balances hidden in one total. It has to be split.
• A second installment lands. A tenant pays ₮300,000, then ₮500,000. If the second payment overwrites the first, the sheet says they still owe money. So it’s split again.
• A cell changed while I was reviewing. The cells have to be read again before anything is written.
• The tenant paid after the report went out. The morning report said they owed ₮200,000. By 15:00 they’d paid. The report is stale, so a new one is needed.
• A send timed out. Did the SMS go or not? Nobody knows until someone checks the history.

None of that is in the documented process. All of it was in my head.

This is the gap that kills AI projects. Give an agent the six-step version and it’ll look great in the demo. Then the first real statement breaks it, and the owner stops trusting it.

You can’t automate what you haven’t watched.

04Step 2: Redesign. Every task gets one of four answers

Once the real work is on the map, you sort it. Every task gets exactly one of four answers:

• Delete. It shouldn’t exist.
• Code. Plain, deterministic code. Same input, same output, every time.
• Agent. Needs judgment over messy input, but the result can be checked.
• Human. A decision that stays with a person.

Here’s how Байр 3 sorted out.

Qualify. The agent checks a prospect against my criteria. Code flags what’s missing. Approving the tenant is my call.

Sign. Code fills the lease and checks the unit row. Re-typing the lease into the sheet is deleted. Countersigning stays with me.

Move in. Staff still do the checks and photos and take the meter readings. Code notifies me. Paper notes are deleted.

Pay rent. The agent matches transfers to tenants. Code writes to the sheet and verifies it. Unclear payments come to me. Matching by hand is deleted.

Remind. Code refreshes the balance. The agent drafts the SMS. I approve the send. Rechecking every balance by hand is deleted.

Maintain. Workers fix the problem and take photos. Code alerts both sides and books the cost once, so a repair report and its bank debit don’t land as two expenses. Forwarding photos around is deleted.

Move out. Staff and I do the exit inspection. Code calculates utilities. Picking deductions stays human. Working out the refund from memory is deleted.

Notice the pattern. The agent shows up less than you’d expect. Most of the lift comes from deleting things and writing boring code.

And notice what stays human: approving tenants, countersigning, unclear money, sending messages, deductions. Those aren’t leftovers. They’re the decisions where a wrong answer costs trust or money.

Deciding where intelligence doesn’t belong is half the redesign.

05Step 3: Evals. Prove it before you trust it

An agent that’s right most of the time is a liability if you can’t tell which time is which.

Agents aren’t deterministic. Run the same input twice and you can get a different answer. You can’t argue that away. You can measure it.

That’s what evals are. A list of real inputs, each with the answer it should get, and a way to check the agent got it.

For rent matching, I think in four kinds of case:

• Normal. The reference has the unit number and the amount matches the rent. Expected: rent, right row, right month.
• Edge. The unit number is glued onto a word. The name is in Latin letters and the sheet has it in Cyrillic. A payment lands on the 1st but belongs to last month.
• Incomplete. No unit, no phone, no name that matches anyone. Expected: “unclear.” Not a guess.
• High-risk. Anything that tempts the agent to do damage. Writing into a formula column. Saying “all clear” after it failed to read the sheet. Resending a message whose outcome is unknown. Expected: it refuses, stops or escalates.

High-risk cases have to pass every time. One failure there outweighs any pass rate.

Then come the checks that run inside the workflow itself, on every run:

• The agent rereads the affected cells before writing, preserves the formulas, and checks the saved values afterward. If anything changed during my review, it comes back to me.
• An unmatched payment is better than a guessed one.
• Before every reminder batch, the agent pulls fresh bookkeeping data. If a payment has arrived, that reminder is dropped.
• Every recipient gets a logged result. A timeout stays “unknown” until the message history is checked.

And one habit: every correction becomes a test case. Each time I said “that’s wrong,” the fix became a rule. The input should become a case too, so the next change can’t quietly break the old fix.

What about KPIs? These are the ones I’d measure for this building:

• Payments matched without me.
• Payments sent to me as unclear.
• Wrong writes caught on read-back.
• Reminders that should never have gone out.

I don’t have numbers for any of them yet. That’s the point of choosing them before deploying: you agree on what “working” means before you need it to be true.

The goal isn’t a perfect agent. It’s an agent whose mistakes are visible.

06Step 4: Deploy. Autonomy is earned, one rung at a time

Deployment doesn’t mean flipping a switch. It means climbing a ladder.

• Rung 1, shadow. The agent reads and proposes. It writes nothing.
• Rung 2, approve each. It acts only after I approve each item.
• Rung 3, approve batch. One approval for a batch, with named exceptions.
• Rung 4, act and report. It handles low-risk items alone and tells me after.
• Rung 5, act alone. Only with a long clean record, cheap undo and regular review.

At Байр 3, sheet writes sit at rung 2. Nothing is written until I reply “Apply.”

Reminders sit at rung 2 to 3. I approve the named units, and I can say “all except one.” An approved message is sent once and never retried blindly. Messages to tenants don’t climb any further. That’s a rule, not a phase.

Moving up takes evidence: eval results, the audit log, a clean record. Moving down should be automatic. A failed high-risk case, a wrong write caught on read-back, or a complaint drops that action a rung until it’s fixed and re-tested.

And everything deploys on top of what already exists. Same Google Sheet. Same bank export. Same Mongolian SMS templates. No migration. If the owner has to learn a new system, you’ve built a second problem.

Now the honest part. Where is Байр 3 today?

The workflows are designed and written up, eight of them, from bookkeeping to move-out. The examples are fictional. Real statement matching and approved sheet updates still need to be tested together. The expense columns still need mapping before the agent writes expenses. The live sending connections for reminders still need validation.

So it’s built and partly tested, and not all of it is live. I’d rather say that than pretend otherwise.

Trust isn’t a setting. It’s a record.

07The method is the product

Back to the K.

The split in the middle isn’t a model upgrade. It’s four steps, done in order:

1. Audit: map what really happens, exceptions included.
2. Redesign: give every task one answer. Delete, code, agent or human.
3. Evals: prove it with cases, checks and visible mistakes.
4. Deploy: on top of existing tools, climbing the ladder only on evidence.

I learned it on a rental building. But nothing here is about rent. An invoice queue, a clinic’s bookings and a sales pipeline all have the same gap between the documented process and the real one.

That’s the skill worth learning now. Not prompting. Not picking a model. Walking into a real operation and making AI work inside it, in a way the owner trusts.

I’m turning this into a self-paced course, built with Grok Bot and Claude Code. Every module ends with something you can use in your own business: an operating map, a step sort, an eval set, an autonomy plan.

If you want to work through it with other people doing the same, join us in AI Architects.

The model was never the product. The method is.

— Anand