What an FDE Must Uncover About Agents During Customer Discovery?

You've done the hard groundwork. In Part 1, you played detective and uncovered the Skills worth building. In Part 2, you mapped the systems and wired up the MCP connections that feed them. The AI now knows how to do the work and can reach the data to do it.

But there's still a human in the loop for every single step - invoking each skill, one at a time, stitching the results together by hand. The final rung of the ladder is where that changes. It's where AI stops waiting to be asked and starts planning, chaining skills across connected systems, and executing multi-step work on its own.

This is the domain of Agents - and discovering agent readiness is the highest-stakes detective work you'll do. Because here, you're not just asking what the AI can do. You're asking a much harder question: how much of the work should the customer be willing to hand over, and are they actually ready to?

Skills discovery was about human behavior. MCP discovery was about systems and access. Agent discovery is about trust, autonomy, and control - and it's where enthusiasm most often collides with organizational reality. This post is what you should care about when you make that final shift.

First, Reframe What You're Really Assessing

An agent is an AI system that plans, reasons, uses tools, and executes multi-step work with minimal hand-holding. Think of Claude Code taking a bug from report to shipped fix, or an autonomous system that scans a portfolio overnight and drafts the outreach before anyone arrives at their desk.

The temptation is to treat agent discovery as a technical question: "can we chain these skills together?" You usually can. The real questions are organizational and human:

• How much autonomy will the customer actually tolerate?
• Where does the risk become unacceptable?
• Who stays accountable when the AI acts on its own?

Every question you ask at this rung should pull on one of three threads: the workflow the agent will own, the trust boundary the organization will accept, and the control mechanisms that keep a human accountable.

What You Should Care About in Discovery

1. Find the Multi-Step Workflows Worth Orchestrating

A single skill is a task. An agent is a workflow - a sequence of skills, decisions, and system actions strung together toward an outcome. During discovery, care about finding processes that are multi-step, repetitive, and mostly rule-governed.

• "Walk me through a process that takes several steps across several tools."
• "Where does someone spend an hour clicking between systems to get one thing done?"
• "Which workflows follow a fairly predictable playbook, even if there are exceptions?"

The best first agents automate the connective tissue - the tedious orchestration between skills - not the moments requiring deep human judgment. Look for the workflow where 80% is mechanical and only 20% needs a person.

2. Map the Decision Points and Their Risk

Inside every multi-step workflow are decision points - moments where the agent chooses a path. Your job is to find each one and understand what's at stake if it chooses wrong.

• "At each step, what decision gets made, and on what basis?"
• "Which of those decisions are safe to automate, and which make you nervous?"
• "What's the worst realistic outcome if the agent makes the wrong call here?"

This is the heart of agent discovery. A workflow where every decision is low-stakes and rule-based is a dream agent candidate. A workflow with a high-consequence judgment call in the middle needs that specific step gated behind a human - even if everything around it runs autonomously.

3. Define the Autonomy Boundary Explicitly

"Autonomous" is a spectrum, not a switch. The single most important thing you'll uncover is where on that spectrum the customer is comfortable operating. Care about drawing this line precisely.

• "Should the agent act and notify you, or propose and wait for approval?"
• "Are there actions it can take freely, and others that always need a human hand on the button?"
• "What would need to be true for you to let it run without reviewing every step?"

Most organizations start with a "human-in-the-loop" posture: the agent does the work and drafts the actions, but a person approves before anything executes externally. Over time, as trust builds, that boundary moves. Discovering where it sits today - and what would move it - is core to scoping a realistic first agent.

4. Establish the Accountability Model

When an agent acts, someone in the organization still owns the outcome. If you don't surface who, you're building something no one will feel safe turning on. During discovery, care about accountability as much as capability.

• "If the agent does something wrong, who is responsible for catching and correcting it?"
• "Whose name is on the outcome when the AI acts on their behalf?"
• "Who has the authority to approve giving the agent this much autonomy?"

Agents blur the line between "the tool did it" and "we did it." The customer needs a clear answer to who owns the agent's actions - and if they don't have one yet, you've just uncovered a governance conversation that has to happen before deployment, not after.

5. Design the Observability and Override

You cannot trust what you cannot see. A production agent needs a way for humans to watch what it's doing, understand why it did it, and stop it when needed. During discovery, care about what visibility and control the customer will require.

• "How would you want to see what the agent did and the reasoning behind it?"
• "Do you need an audit trail of every action for compliance or review?"
• "How do you want to be able to pause, intervene, or roll back?"

Even a highly autonomous agent should leave a legible trail and offer a clear off-switch. Uncovering these requirements early shapes the whole design - because bolting on observability after the fact is painful, and its absence is a dealbreaker for most serious organizations.

6. Assess Organizational and Cultural Readiness

This is the factor FDEs most often underestimate. An agent doesn't just change a workflow - it changes what people's jobs are. The team shifts from doing the work to directing and reviewing the AI that does it. Not every organization is ready for that shift, and discovery is where you find out.

• "How does the team feel about AI taking over parts of their work?"
• "Are people worried about being replaced, or excited to offload the tedious parts?"
• "Is leadership prepared to redefine roles around reviewing AI output rather than producing it?"

The most technically sound agent will fail if the people around it don't trust it or feel threatened by it. Care about the human change management as seriously as the technical design. Sometimes the right recommendation is to not deploy an agent yet - and to build trust through skills and assisted workflows first.

7. Gauge the Readiness of the Foundation Beneath It

An agent is only as good as the skills and MCP connections it orchestrates. Before recommending an agent, care about honestly assessing whether the lower rungs are solid.

• "Are the individual skills this agent would use reliable enough to trust in sequence?"
• "Are the MCP connections clean, current, and permission-appropriate?"
• "Have we proven each piece works on its own before chaining them together?"

Errors compound in a multi-step agent - a skill that's 95% reliable used across five chained steps produces a meaningfully less reliable outcome. If the foundation is shaky, the honest FDE move is to strengthen it before adding autonomy on top. Agents amplify whatever is beneath them, for better or worse.

The Discovery Mindset for the Agent Layer

If Skills discovery made you an anthropologist of work and MCP discovery made you a cartographer of systems, Agent discovery makes you something closer to a risk advisor and change partner. You're no longer just uncovering what's possible - you're helping the customer navigate what's wise.

Three habits set great FDEs apart at this rung:

Earn autonomy incrementally. Resist the pressure - internal or external - to jump straight to a fully autonomous agent. Start with the agent proposing and a human approving. Let trust accumulate through demonstrated reliability, then widen the boundary. Trust is earned in production, not promised in a demo.

Design for failure, not just success. The customer's real question isn't "what happens when it works?" - it's "what happens when it doesn't?" An FDE who has clear, confident answers about observability, override, and accountability wins trust that no capability demo can buy.

Know when the answer is 'not yet.' The most valuable thing you can sometimes tell a customer is that they're not ready for an agent - that their skills need hardening, their data needs cleaning, or their team needs time. Recommending restraint is a mark of a senior FDE, and it protects the long-term relationship over the short-term win.

Closing the Loop

Across three posts, you've walked the full AI adoption ladder from a Forward Deployed Engineer's chair:

Skills - you learned to uncover the scoped, repeatable capabilities worth building, by studying how people actually work.

MCP - you learned to map the systems and access that let those skills reach real data, by tracing the terrain and partnering with the people who own it.

Agents - you learned to assess whether and how much of the work the AI should orchestrate on its own, by weighing trust, autonomy, control, and organizational readiness.

Here's the thread running through all three: your real product as an FDE was never the code. It was the understanding you built before you wrote it - the discovery that separated the valuable from the merely impressive, the ready from the not-yet, the wise from the possible.

The teams that will win with AI aren't the ones who climb the ladder fastest. They're the ones who climb it deliberately, one solid rung at a time - and who have an FDE beside them asking the right questions at every step.

That FDE is you.