# FDE Starter Plan and Transcript Walkthrough

## Approach and assumptions

This walkthrough treats the transcript as a sales-oriented teaching source. It separates its useful operating model from its promotional claims.

The four-page PDF is a compressed summary of the transcript. It preserves the core loop and weekly checkpoints. It omits much of the transcript's business reasoning, examples, and caveats.

The strongest interpretation is:

> In 30 days, build one FDE-grade case study with evidence. Do not claim 30 days of work equals mastery of the role.

![FDE mind map](/Users/siddchauhan/Documents/Rm_Obsidian_Logseq/CodexProjects/fde-30-day-os/visuals/08-fde-mind-map.png)

## Section 1. Why the role exists

### Transcript thesis

The transcript starts with a market thesis:

• Companies increasingly buy access to similar frontier models.

• Raw model access therefore provides less differentiation.

• The advantage moves to where a company applies AI, how it applies AI, and why it selects one workflow over another.

• The FDE owns those deployment choices.

![Where value moves](/Users/siddchauhan/Documents/Rm_Obsidian_Logseq/CodexProjects/fde-30-day-os/visuals/01-where-value-moves.png)

### What this means

A model is an engine. The business still needs someone to select the vehicle, map the route, set speed limits, instrument the dashboard, and decide when a person takes the wheel.

The role does not derive its value from writing prompts. It derives value from converting a messy business process into a reliable system with measurable economic impact.

### What holds up

Palantir's current career material describes forward-deployed work as finding the real customer problem, breaking it into workflows, aligning stakeholders, building the technical solution, and producing operational outcomes. This supports the transcript's broad role definition.

### What needs qualification

The statement “everyone has the same intelligence” overstates the case. Companies differ in:

• Model access and pricing

• Data quality

• Security and compliance limits

• Infrastructure

• Evaluation maturity

• Staff skill

• Distribution and customer access

The better claim is: model access alone rarely creates durable value. Deployment quality often creates more differentiation.

## Section 2. What an FDE does

### Transcript definition

The transcript defines a three-part transformation:

1. Understand business reality.
2. Decide where AI belongs.
3. Deploy a working system.

![The FDE job](/Users/siddchauhan/Documents/Rm_Obsidian_Logseq/CodexProjects/fde-30-day-os/visuals/02-fde-job.png)

### Part 1. Understand business reality

The FDE studies how work happens today:

• Who starts the work

• Which systems hold the data

• Where people re-enter data

• Which approvals cause delays

• What exceptions occur

• Which rules live only in one employee's head

The transcript argues for observation and interviews. A one-hour meeting gives the official process. Sitting with an operator exposes the edge cases.

### Part 2. Exercise FDE judgment

The FDE separates the workflow into three types of work:

• Deterministic software for stable rules

• Model judgment for ambiguous classification, extraction, drafting, or reasoning

• Human judgment for high-risk, low-confidence, or politically sensitive action

This is one of the transcript's strongest ideas. An AI project should not place a model in every step.

### Part 3. Deploy a working system

The output is not a presentation or prototype. The output is software carrying a defined amount of operational responsibility.

Different companies use the FDE title differently. Some roles require production software engineering. Some focus on configuring a platform, writing SQL, integrating systems, or designing workflows. Read each job description as its own specification.

## Section 3. The two-sided skill profile

### Transcript model

The transcript places commercial judgment on one side and technical judgment on the other.

![Two worlds, one FDE](/Users/siddchauhan/Documents/Rm_Obsidian_Logseq/CodexProjects/fde-30-day-os/visuals/03-two-worlds.png)

### Commercial judgment

• Workflow discovery

• Cost and value analysis

• Incentives and company politics

• Risk and adoption

• Stakeholder communication

• Prioritization

### Technical judgment

• Models and APIs

• Data and schemas

• Agent loops and tools

• Reliability and recovery

• Evals and guardrails

• Logging and monitoring

### The key standard

The transcript says the best FDE is not mediocre at both sides. The person translates between both sides and owns the end-to-end outcome.

The phrase “perfect at both” is promotional. Real teams distribute expertise. A credible candidate needs enough depth to make decisions, implement the scoped system, and know when to involve a specialist.

### Relevance to Sidd

Your likely advantage sits on the commercial and product side:

• Accenture client context

• Workflow analysis

• Product and marketing work at Wedify

• Communication and portfolio presentation

Your proof gap is deeper production evidence:

• Failure recovery

• Evaluation datasets

• Measured accuracy and cost

• Explicit system boundaries

• Spoken architecture defense

The 30-day project should close this proof gap. It should not restart your portfolio from zero.

## Section 4. Workflow reality and the audit

### Transcript example

The official process says “an email arrives.” Reality includes:

• More than 40 senders

• PDFs, screenshots, spreadsheets, and forwarded threads

• Missing or stale attachments

• Inconsistent subjects

• Prior approvals hidden in conversation history

• Routing rules stored as tribal knowledge

![Map real work](/Users/siddchauhan/Documents/Rm_Obsidian_Logseq/CodexProjects/fde-30-day-os/visuals/04-map-real-work.png)

### Audit output

A useful audit or “workflow sprint” produces:

1. Current-state map. The real steps, handoffs, systems, delays, and exceptions.
2. Future-state map. The proposed division among software, model, and human.
3. Selected use case. One workflow chosen for value and feasibility.
4. Boundaries. Actions the system has and does not have authority to take.
5. Expected value. Time saved, cost reduced, risk reduced, or revenue affected.

### Selection rule

Prioritize work with:

• Sufficient volume

• Material pain or error cost

• Accessible data

• Clear outputs

• Repeated judgment

• Manageable risk

Do not start from “Where can I add AI?” Start from “Which bottleneck matters, and what mechanism causes it?”

### Money angle

The audit itself has commercial value when it identifies a costly process and gives the buyer a defensible priority map. The transcript suggests free audits for early experience. Use a strict boundary: one workflow, one map, one decision memo. A broad free audit becomes unpaid consulting.

## Section 5. Evals and trust

### Transcript definition

Evals turn non-deterministic behavior into evidence.

![Evidence, not hope](/Users/siddchauhan/Documents/Rm_Obsidian_Logseq/CodexProjects/fde-30-day-os/visuals/05-evidence-not-hope.png)

### Golden dataset

The plan asks for at least 20 real queries with hand-labeled expected outputs. The set should include:

• Normal cases

• Edge cases

• Ambiguous cases

• Missing-data cases

• High-risk cases

### What to grade

• Correct data selected

• Required steps completed

• Output schema valid

• Correct tool selected

• Expert result matched

• Unsafe action stopped

• Low-confidence case escalated

### What a report should show

• Total cases

• Pass rate

• Failure categories

• Escalation rate

• Cost per run

• Latency

• Open risks

• Readiness level

### Important limit

Twenty cases create a useful starter set. They do not establish production reliability for a high-risk workflow. Sample size, coverage, data drift, and real-world distribution still matter.

The practical goal for day 21 is not “the agent works.” The goal is “I know where it works, where it fails, and when it asks for a person.”

## Section 6. Deployment and adoption

### Transcript position

Build over existing systems. Do not make a costly platform migration the price of trying the agent.

![Earn more control](/Users/siddchauhan/Documents/Rm_Obsidian_Logseq/CodexProjects/fde-30-day-os/visuals/06-earn-more-control.png)

### Staged deployment

1. Sandbox. Use safe data and limited permissions.
2. Shadow mode. Run the agent beside the existing process without letting it act.
3. Human gate. Let the agent prepare work while a person approves every action.
4. Limited autonomy. Grant one narrow action after evidence supports it.
5. Wider scope. Expand only after monitoring shows stable behavior.

### Adoption logic

The buyer faces career risk. A failed AI rollout damages credibility. A strong FDE reduces perceived risk through:

• Small scope

• Reversible actions

• Clear logs

• Human approval

• Known failure behavior

• Measured value

### What the starter plan omits

The PDF does not give enough attention to:

• Authentication and access control

• Data privacy and retention

• Compliance

• Secrets management

• Incident response

• Monitoring and service levels

• Ownership after handoff

• User training

These belong in a serious FDE case study, even if the demo uses synthetic data.

## Section 7. The 30-day roadmap

The starter plan compresses the transcript into four phases. The interactive guide provides the exact daily sequence.

![Thirty days to proof](/Users/siddchauhan/Documents/Rm_Obsidian_Logseq/CodexProjects/fde-30-day-os/visuals/07-thirty-days-to-proof.png)

### Week 1. Build the agent

Goal: complete one useful workflow and expose every step.

| Day | Focus | Evidence required |
|---:|---|---|
| 1 | Agent loop | A loop with a max-step limit |
| 2 | Tool use | One API call and one search or second tool |
| 3 | Guardrails | Input checks, step cap, and output filtering |
| 4 | Context and memory | A written reason for what persists and what does not |
| 5 | Audit trail | Prompt, response, tool call, result, error, timestamp |
| 6 | Real workflow | One end-to-end run tied to a real process |
| 7 | Checkpoint | Working agent, tools, guardrails, memory, and logs |

### Week 2. Make it recoverable

Goal: produce predictable outputs and resume after failure.

| Day | Focus | Evidence required |
|---:|---|---|
| 8 | Structured output | Defined JSON schema |
| 9 | Schema validation | Retry or escalation on invalid output |
| 10 | Failure modes | Missing data, bad output, dead API, timeout, duplicate, partial run |
| 11 | Checkpointing | Saved task, actions, results, pending work, and errors |
| 12 | Resume | A stopped run restarted from saved state |
| 13 | Failure handling | Explicit behavior for each unsafe or incomplete state |
| 14 | Checkpoint | Resumable system with structured output and recovery |

### Week 3. Measure and optimize

Goal: know how the system fails, what it costs, and whether it improves.

| Day | Focus | Evidence required |
|---:|---|---|
| 15 | Retry logic | Backoff on external calls with a capped delay |
| 16 | Failure taxonomy | Named categories for every failed run |
| 17 | Golden dataset | 20 labeled cases across normal, edge, ambiguous, and high-risk work |
| 18 | Run evals | Scores for correctness, format, tools, steps, and escalation |
| 19 | Cost | Cost per query, token limits, caching, and model routing |
| 20 | Multi-agent decision | Evidence for using decomposition or a written decision to stay single-agent |
| 21 | Checkpoint | Eval report, known failures, cost, and golden dataset |

### Week 4. Communicate and defend

Goal: explain the system to an engineer and an executive.

| Day | Focus | Evidence required |
|---:|---|---|
| 22 | Pain point | Owner, time, errors, frequency, and cost |
| 23 | Why AI belongs | Why rules alone fail, what stays human, where autonomy stops |
| 24 | Architecture | Stack, data, tools, models, memory, and guardrails |
| 25 | Iterations | What version one got wrong and what changed |
| 26 | Evals | Dataset, pass rate, failure types, thresholds, and open risks |
| 27 | Economics | Time, errors, risk, revenue, and cost per run |
| 28 | Engineer rehearsal | Architecture, choices, failures, and tradeoffs |
| 29 | VP rehearsal | Problem, outcome, evidence, and risk in plain language |
| 30 | Final checkpoint | Complete case study and two spoken pitches |

## Section 8. Claims requiring a reality filter

### Unverified. “FDEs earn $150,000 to $1 million per year”

The transcript and PDF make this claim. They do not provide compensation data. Some FDE roles pay high software-engineering compensation. The $1 million upper bound likely describes rare senior offers, equity outcomes, or isolated cases. Do not use it as an expected salary.

### Unverified. “95% of generative AI pilots fail”

The transcript attributes this figure to MIT without naming the report, sample, or definition of failure. Treat it as a promotional statistic until the original study and methods support the exact wording.

### Unverified. “A company spent its $10 million Claude budget in three months”

This is an anecdote without a named company or evidence. The lesson about uncontrolled usage and weak ROI is plausible. The number is not verified.

### Overstatement. “Every company uses the same stack”

Many teams use overlapping tools. Enterprise architecture, security, data, budgets, and model access still differ.

### Overstatement. “Become an FDE in 30 days”

Thirty days supports a first case study. It does not establish mastery of software engineering, enterprise delivery, or stakeholder management.

## What the transcript gets right

• Start from the real workflow.

• Use deterministic code for deterministic work.

• Reserve models for judgment.

• Keep people in high-risk loops.

• Build evals before claiming reliability.

• Log actions before asking for trust.

• Integrate with existing systems.

• Increase autonomy through evidence.

• Translate technical behavior into business value.

## If you only complete five days

1. Day 6. Proves the system completes a real workflow.
2. Day 10. Forces you to map the unhappy paths.
3. Day 17. Creates the evidence base.
4. Day 27. Connects the build to money, risk, and time.
5. Day 29. Tests whether a buyer understands the value and trusts the scope.

## Sidd's best project choice

Recommendation: deepen Briefline or another existing event-driven agent instead of starting a fourth new demo.

Why Briefline fits:

• It already represents a multi-step business workflow.

• It already has external inputs and provider calls.

• Deduplication and SSRF controls provide security and failure stories.

• It has a visible Slack-style interface for an executive demo.

• The missing work aligns with the plan: state recovery, golden dataset, eval report, measured cost, business economics, and two audience-specific pitches.

If Briefline lacks a real operator and real examples, use one Wedify workflow with Joel or another team member as the domain expert. Real workflow access has more value than a cleaner fictional demo.

## 😈 Devil's Advocate

Your failure mode is building the tracker, polishing visuals, and calling the learning complete.

The tracker has no career value by itself. The case study, test evidence, spoken defense, and five operator conversations create value.

## Overthinking looks like

• Comparing five agent frameworks before choosing one

• Starting a new project because the old one feels less clean

• Redesigning the interface before collecting 20 cases

• Waiting for the perfect enterprise workflow

• Studying multi-agent systems before one agent recovers from failure

## Single next step

Select one workflow and write a one-sentence contract:

> When [trigger] occurs, the system uses [inputs and tools] to produce [output], stops at [human boundary], and improves [time, cost, risk, or revenue metric].

## Sources

• [Varick interactive FDE guide](https://learn.varickagents.com/fde-in-30-days)

• [Palantir careers role overview](https://www.palantir.com/careers/index.html)

• [Palantir open positions](https://www.palantir.com/careers/open-positions/)

• User-provided transcript and FDE Starter Plan PDF