First, Draw a Boundary Line: What FDE Does Is Not the Same as "Developing an Agent"
Before we dive deeper, we must firmly establish a boundary that is often confused; otherwise, all subsequent practical discussions will slip back into the old trajectory of "technical implementation."
Developing an intelligent application, developing an Agent, or even developing a Harness Agent — which packages multiple tools, multi-step reasoning, and execution environments into a closed autonomous task unit — fundamentally answers the same type of question: "Can this system complete a specific task?" This type of question has clear acceptance criteria — whether functionality is implemented, whether accuracy metrics are met, whether response speed is adequate, whether interfaces are stable. The technical team can independently complete the entire cycle from design to testing, with the business side playing the role of defining requirements and accepting functionality.
FDE answers a fundamentally different dimension of question: "After the organization introduces this capability, have business outcomes genuinely improved, and can this improvement be proven, attributed, and sustained?" This type of question has no one-time acceptance criteria, because business outcomes themselves are a continuous curve, not a single delivery milestone. This means the scope of FDE work must necessarily cover the entire chain of discovery, planning and assessment, advisory and design, implementation and embedding, impact tracking, and outcome ownership — Agent development is merely one specific technical approach within the "implementation" link of this chain, not the chain itself.
Below, we break this chain into six stages and walk through the operational details of each.
Stage One: Discovery and Problem Reframing — Not Gathering Requirements, but Co-discovery
The starting point of traditional projects is a requirements document: the client states what they want, and the vendor assesses feasibility. FDE's starting point is precisely the opposite — what the client says is often not the real problem, but rather the symptom of the problem. This is why the "Co-discovery" methodology exists, and it's where FDE diverges from traditional implementation teams at the very first step.
How does this work in practice? Take the consumer finance scenario of Lianghuapai as an example. The business side's initial requests typically focus on a specific pain point, such as "collection efficiency is too low." But the authentic discovery process requires tracing backwards along business object relationships: collection efficiency is low because the relationships among CollectionCase, Transaction, and CreditApplication lack structured representation, preventing collection strategies from being dynamically adjusted based on the borrower's complete credit trajectory. The business side itself cannot articulate this real problem — all they can perceive is the symptom of "low efficiency." The FDE team must systematically sort through the relationships among core objects like Borrower, CreditApplication, Transaction, CollectionCase, and MarketingChannel to reduce the symptom to a structural problem.
Take ChainUp's ChainEyes KYT compliance product as another example, where the problem discovery approach differs again. The symptom here was not "missing features," but a more subtle condition — "implicit ontology" : strong engineering capabilities were already in place (20 APIs, 43 code modules of the Trustformer classification system were already operational), but there was a lack of explicit, documented ontology assets. In this case, discovery work was not about "building what the client asks for," but rather about reverse-engineering seven source documents and OKR reports spanning approximately 15 months to identify genuine structural gaps — such as the absence of explicit transaction hash foreign keys in Input/Output tables, a data integrity issue that the client team may not have recognized in daily operations as a risk requiring explicit representation and governance.
These two cases illustrate one key point: the core output of the discovery stage is not a requirements specification, but a "structural diagnosis of the problem." It must answer what object relationships underlie the symptoms, at which level the gap resides (data layer, process layer, governance layer), and who should be accountable for this gap. This diagnosis is the foundation upon which all subsequent planning, design, and implementation work rests.
Stage Two: Planning and Feasibility Assessment — Replacing Vague "Can We Do It" Judgments with Quantified Completion Metrics
When facing a project, traditional implementation teams typically evaluate along the dimension of "technical feasibility" — whether a particular function can be implemented with the existing technology stack. FDE's assessment in Stage Two is fundamentally different, centered on answering two questions: At what level is this organization's current methodological maturity, and which tasks can be delegated to AI versus which must retain human review?
The first question requires specific quantitative benchmarks, rather than vague statements like "overall good" or "room for improvement." Taking the Lianghuapai project's assessment as an example, methodological completion was broken down into two independent dimensions with separate scores — consulting methodology completion at approximately 60%, while ontology modeling completion stood at about 20%. The gap between these two numbers is itself a critical insight: it reveals that the organization has substantial accumulation in "business understanding and process design," but significantly lags in "translating business understanding into structured ontology that systems can consume." This insight directly determines the design focus of Stage Three — not redoing business consulting, but prioritizing the completion of ontology modeling capabilities.
The second question — which tasks to delegate to AI versus which to keep under human review — needs clear boundaries established during the planning phase, rather than being addressed after implementation is complete. There is an easily overlooked yet critically important practical lesson here: during the ChainEyes project assessment, a "role boundary risk" was identified — the FDE lead's OKR scope had been extended to business operation metrics, exceeding the typical boundaries of FDE technical delivery. This discovery itself is one of the most valuable outputs of the planning stage: it reminds us that FDE responsibility boundaries must be contractually defined at project initiation; otherwise, "outcome ownership" can easily devolve into unlimited responsibility diffusion — FDE teams being held accountable for business outcomes beyond their technical control, which is both unfair and dilutes the focus on genuine technical governance.
The output of the planning stage, therefore, should be a joint document that combines "capability benchmark assessment" and "task boundary delineation," rather than a simple project timeline.
Stage Three: Advisory and Architecture Design — Translating Business Understanding into Contracts Consumable by Systems
This is the most technically intensive stage of the entire chain, yet also the most easily misunderstood as "just designing an application." The distinction is this: Agent development designs "how this function is implemented"; FDE advisory and architecture design addresses "how this business concept is structurally represented so that any subsequent Agent, any model invocation, operates within a unified semantic framework."
Specific design activities encompass two categories of core deliverables:
First, Ontology Specification. This is not a database schema design, but a three-in-one specification that includes JSON Schema definitions, sample data, and extraction methodology. Taking the Lianghuapai project as an example, each of the six core object types — Borrower, CreditApplication, Transaction, CollectionCase, MarketingChannel, and CodeGenTask — requires explicit definition of its field semantics, cardinality relationships with other objects, and specific methods for extracting object instances from raw business data. The value of this document lies in its role as the sole authoritative basis for any subsequent Agent to correctly understand "what a collection case is and what its relationship is to a credit application." Without this contract, regardless of how advanced the models integrated later may be, business semantics will be distorted as they flow between systems.
Second, Link Type Contract. This is a finer-grained and more easily overlooked design deliverable than the ontology itself. Using the ChainEyes project as an example, the delivered Link Type contract document defined 21 relationship types (LNK-01 through LNK-21), specifying for each the object types it connects, cardinality constraints, whether nulls are permitted, and audit requirements. The practical value of such documents lies in the fact that the most error-prone and hardest-to-repair aspects of enterprise systems are often not individual object field definitions, but rather implicit assumptions about relationships between objects — such as whether a transaction record must be associated with a specific transaction hash. If this foreign key relationship is not explicitly contracted, the system may operate for extended periods with data integrity gaps without anyone being aware of them.
The architecture design at this stage also requires upward mapping to the enterprise's layered technology architecture — infrastructure layer, AI algorithm services layer (knowledge computation engine), technical solution middleware layer (orchestration, bot factory, AI studio), product solution layer (knowledge management, ESG, KYT compliance), and product application layer. FDE's design work determines at which layer the client's current problem should be addressed — often, the business side thinks it needs a new application (product application layer), but the real gap actually lies in the middleware layer (missing orchestration capabilities) or even lower in the ontology modeling layer. Without this layer mapping, "over-engineering" or symptomatic rather than root-cause implementation misalignment is likely.
Stage Four: Implementation — Business Process Embedding, Not Feature Development
By the implementation stage, specific technical work such as Agent development, model invocation, and orchestration engine configuration finally takes center stage. However, it must be emphasized that these technical activities are means of the implementation stage, not its ends. The true goal of implementation is to embed the ontology contracts and relationship contracts designed in Stage Three into the client's actual approval flows, task flows, and decision flows — and to equip this embedding with risk-tiered governance capabilities.
Hierarchical authorization governance is the most critical practical mechanism at this stage. Taking the design logic of HaxiTAG's Agus system as an example, it simultaneously assumes three roles — autonomous executor, risk gatekeeper, and decision collaborator. The specific tiering logic is: within low-risk, reversible, and auditable operational boundaries (such as routine data processing and monitoring inspections), the system can proactively execute in an Agent capacity; within high-risk, irreversible boundaries (such as critical nodes involving fund transfers or compliance determinations), the system switches to a Copilot + Governor collaborative mode — outputting analysis and recommendations only, awaiting human approval before execution. The key design principle of this mechanism is that risk tiering is not a one-time configuration, but rather requires determining the risk level of each operation type on a case-by-case basis, combining the business object relationships identified in Stage One with the cardinality constraints designed in Stage Three. This is also why implementation cannot be independently conducted in isolation from the preceding three stages — without the structured understanding from Stage One of the relationship between collection cases and credit applications, the implementation team simply cannot determine which risk tier "automatically adjust collection strategy" should be assigned to.
Another practical action at the implementation stage that is easily underestimated is quality threshold setting and validation. Taking the implementation experience of GridMind's energy intelligence product as an example, during the pre-delivery validation process, the system needed to pass complete validation across 39 test cases, during which four categories of typical issues were identified and fixed — division-by-zero errors, non-determinism from random seeds, parameter calibration for OU process mean reversion (κ adjusted from 2.5 to 3.5), and SCED clearing gap handling logic. The common characteristic of these issues is that they are not "functionality not implemented" defects, but rather "whether the system is trustworthy under boundary conditions" defects — a division-by-zero error that is not systematically tested during implementation may only surface under extreme market conditions in production, and when it does, the consequence will not be a functional failure but a business decision error. This is precisely the key distinction between "implementation" and "development" — development cares whether the feature works; implementation cares whether the system is trustworthy under the boundary conditions of real business.
Stage Five: Impact Tracking — Accepting with Business Metrics, Not System Launch
Traditional projects treat system launch as the acceptance point; FDE's acceptance point is a continuous business metric curve. This is the most direct operational expression of the principle "oriented toward project outcome value rather than task completion."
Impact tracking requires a multi-dimensional quantitative indicator system, rather than a generic "customer satisfaction." It can be broken down into four dimensions:
Decision Quality Dimension: Whether business users, after introducing the system, show improvements in key decision accuracy and response speed that can be attributed to system capabilities — rather than a vague "feels faster."
Risk Exposure Dimension: Whether audit trails are complete, what the recall rate of anomaly detection is, and whether data integrity gaps (such as the transaction hash foreign key issue mentioned earlier) have been systematically fixed and incorporated into ongoing monitoring.
Cost and Efficiency Dimension: Specific savings in labor hours and reductions in process cycle times, with the ability to attribute these savings to specific sources — whether they came from automated collection strategy or compressed compliance review processes — rather than blanket attribution to "adopting AI."
Organizational Capability Accumulation Dimension: This is the most easily overlooked yet most critical dimension for "outcome ownership" — whether, after the project concludes, the client organization itself has acquired the ability to sustain and iteratively evolve the system, or whether every business rule change still requires external team re-engagement.
The output of impact tracking should be a periodic assessment report rather than a one-time acceptance report. Such reports should themselves be auditable — what are the original data sources underlying the assessment, is the assessment method reproducible, and does the conclusion have a clear chain of evidence. Taking the ChainEyes project as an example, the final deliverable was a Markdown assessment document accompanied by a 26-row CSV checklist. The value of the checklist lies in translating abstract "assessment conclusions" into specific, checkable, traceable items that can be reused and compared in the next assessment cycle — this itself exemplifies the engineering of impact tracking mechanisms.
Stage Six: Outcome Ownership — Turning Accountability from Slogan into Contracts and Review Mechanisms
If "outcome ownership" remains only at the level of attitude, it can easily degenerate into an unverifiable public relations talking point. To genuinely transform it into an executable mechanism requires three specific institutional designs:
First, Contractualization of Responsibility Boundaries. The risk case mentioned earlier — "the FDE lead's OKR scope extended beyond technical delivery boundaries" — precisely illustrates that responsibility boundaries must be contractually defined in writing at project initiation: which business metrics the FDE is accountable for, for which metrics it only plays a supporting role rather than bearing ultimate responsibility, and how accountability is to be delineated for business outcomes beyond technical control. Without this contractualization, "outcome ownership" either becomes empty rhetoric or devolves into uncontrolled diffusion of responsibility.
Second, Institutionalization of Periodic Reviews. The deep review assessments produced by projects like Lianghuapai and ChainEyes — covering retrospective presentations at the hundred-page level, multi-dimensional methodological completion scoring, and structured improvement checklists — are themselves the institutionalized implementation of the concept of "sustained accountability." Such reviews are not project acceptance reports, but rather diagnostic starting points for the next iteration cycle, meaning that even after the project has "gone live," the accountability relationship between the FDE team and the client organization has not terminated, but has entered the next cycle of "discovery — planning — design — implementation — tracking."
Third, Productization of Reusable Methodologies. The structural problems identified in each specific project — ontology gaps, missing relationship contracts, role boundary risks, data integrity issues — should all be abstracted into reusable methodology components that feed back into general assessment frameworks such as enterprise-grade AI data readiness. For example, the tiered "L1 to L6" data readiness model, combined with supporting self-assessment scorecards, enables the next client to directly reuse this benchmark during the Stage One discovery phase, without having to grope for diagnostic methods from scratch each time. This is the critical step that elevates "outcome ownership" from a single-project accountability promise to organizational-level methodological asset accumulation — and it is the fundamental distinction that sets FDE teams apart from one-off project outsourcing teams.
The Six Stages Combined Are What Constitute "FDE" — Not Any Single One of Them
When the six stages are placed side by side, an easily overlooked fact comes into focus: Agent development, model invocation, and orchestration engine configuration appear only in part of Stage Three's work and all of Stage Four's work — accounting for roughly one-third of the entire chain. Yet the problem reframing of Stage One, capability assessment and boundary delineation of Stage Two, business metric tracking of Stage Five, and responsibility contractualization and methodology accumulation of Stage Six — the work depth and professional intensity of these four stages are equally critical variables determining project success, yet they are often completely overlooked in simplified narratives like "should we build an Agent."
This is also why the statement "FDE is defined by customer responsibility, not by skills" has a concrete meaning when translated into operational reality: it means the FDE team's core deliverable is never a specific technical component, but rather a complete chain of accountability that spans six stages and can be audited, reviewed, and iterated continuously. Technical components become obsolete; models iterate; but this chain of accountability — from structural diagnosis of problems, to clearly bounded contract design, to risk-tiered implementation governance, to attributable business metric tracking, to institutionalized reviews and methodology accumulation — is the core asset that client organizations genuinely need and are truly willing to pay for on an ongoing basis.