Outcome-Driven Agentic Design

Why it exists

Software organizations have spent decades optimizing implementation.

As AI increasingly automates research, coding, testing, and documentation, implementation is becoming faster and less expensive. The bottleneck is shifting elsewhere. The limiting factor is increasingly not whether teams can build software, but whether they can clearly define what should be built and how success should be measured.

Traditional delivery methods struggle with this challenge. Discovery artifacts, design work, architecture decisions, and implementation plans often live in separate systems with different levels of fidelity and ownership. As work moves between disciplines, assumptions accumulate and intent degrades.

The cost of those gaps was manageable when software delivery moved at human speed. As AI-assisted delivery accelerates implementation, the cost of ambiguity increases. Agents can generate code quickly. They cannot determine whether the organization has accurately defined what great looks like.

ODAD was developed to address both problems at once.

Before implementation begins, teams create a declaration of intent: a chain of permanent documents that describes the system at progressively increasing levels of resolution. Plans then close the gap between that declaration and current reality. Once completed, plans are deleted. The declaration remains.

The declaration is not documentation about the system. It is the system viewed at different levels of magnification. The north star is the system zoomed all the way out. The design is the system at architectural resolution. The code is the system at maximum magnification. Each layer validates and constrains the next.

The goal is not faster delivery. The goal is reducing the distance between organizational intent and production reality.

My role

While the methodology itself was formulated by our Director of UX, the UX organization played a central role in shaping, operationalizing, and scaling it across the business. My contribution sat at the intersection of methodology design, cross-functional alignment, and organizational adoption.

A core principle of ODAD is that different disciplines serve as authorities within different parts of the declaration. Product contributes business context and outcomes. Engineering contributes technical feasibility and architecture. QA validates system behavior. UX serves as the human authority responsible for validating findings, north stars, and flows, ensuring they accurately reflect customer needs, user behavior, and real-world workflows.

My responsibilities included:

• Helping define and refine the agreement layers where Product, UX, QA, and Engineering establish shared intent before implementation begins
• Acting as a UX authority during declaration reviews, validating that findings, north stars, and flows reflected customer reality rather than organizational assumptions
• Leading adoption across PM and design teams by connecting the methodology to existing discovery, research, and design practices
• Auditing both new and in-flight initiatives to identify where ODAD could improve clarity, alignment, and delivery outcomes
• Establishing structured feedback loops between delivery teams and leadership to ensure the methodology evolved through real-world application

As the rollout expanded, my role increasingly became one of stewardship. The challenge was not simply teaching teams a new process. It was helping teams build confidence that the declaration accurately represented customer intent before it became architecture, plans, and ultimately production software.

The five layers

Layer	The question	Permanence
Findings	What is true right now?	Permanent
North Star	What should be true?	Permanent
Flows	What must the system do?	Permanent
Design	How could it be built?	Permanent
Plans	What is not true yet?	Deleted when complete

Findings

Findings synthesize everything known about the problem space: production telemetry, customer feedback, support interactions, market research, stakeholder knowledge, and existing system behavior.

This layer grounds every subsequent decision in evidence rather than assumption.

UX plays a significant role here because much of what teams know about customers exists outside the codebase. Findings create a shared understanding of reality before anyone begins declaring what should change.

North star

North stars define success from the user’s perspective using testable outcome statements. Not features. Not architecture. Outcomes.

For example:

A group leader should be able to see who attended last week without leaving the group page.

North stars deliberately avoid implementation details. Their purpose is to establish what success looks like before discussing how to achieve it.

One of the key design challenges in shaping the methodology was ensuring this layer remained accessible to non-engineers. If Product and UX cannot meaningfully participate in defining success, the declaration collapses into technical assumptions.

Flows

Flows describe the processes that make north star outcomes real, including both success paths and failure modes.

This layer forces teams to reason about complexity before committing to architecture.

Failure modes discovered in flows are inexpensive to address. Failure modes discovered in production rarely are.

Design

The design layer specifies architecture, contracts, implementation strategy, and trade-offs.

While engineering-led, it remains accountable to the flows and outcomes defined earlier in the declaration.

Every design must answer three questions:

• How does a developer know this works locally?
• How does CI know this works in pull requests?
• How does the team know this works in production?

Verification is treated as an architectural concern, not an afterthought.

Plans

Plans are the only temporary artifact in the system.

Rather than task lists, plans consist of truth statements describing what must become true for the work to be complete.

For example:

When a household has a primary and spouse, generateHouseholdMailingName returns “John and Jane Smith.”

An agent can verify that statement. It cannot verify a task such as “implement salutation logic.”

Once the truth statements are true, the plans are deleted. The declaration remains.

The agreement layer

Most delivery methodologies optimize for handoffs. ODAD deliberately optimizes for agreement.

The highest-risk decisions in software development are rarely technical. They occur when teams believe they are solving the same problem while operating from different assumptions. The agreement layer exists to resolve those differences before implementation begins.

Phase	Participants	Purpose
Agree	Product, UX, QA, Engineering	Validate findings, define north stars, establish flows
Shape	Engineering and UX	Develop functionality and supporting design assets
Polish	Engineering and UX	Refine directly against working software
Verify	QA and Engineering	Validate outcomes against the declaration

UX plays a unique role during the agreement phase.

While AI agents and engineering teams can synthesize information, UX serves as the authority responsible for validating whether findings, north stars, and flows accurately represent customer reality. This includes challenging assumptions, identifying missing context, validating workflow models, and ensuring outcomes remain grounded in evidence.

The result is that implementation begins only after teams have agreed on what success looks like and why it matters. The declaration becomes a shared commitment rather than a document handed from one discipline to another.

Why each layer validates the one before it

ODAD is intentionally structured as an error-correction chain.

Each layer validates the assumptions made in the previous layer:

• Does every north star trace back to evidence in findings?
• Does every north star have flows that make it achievable?
• Does the architecture support the flows and failure modes?
• Does every design have plan coverage?
• Are the truth statements in the plans actually true in the running system?

The earlier an error is discovered, the less expensive it is to correct.

An incorrect assumption identified in a north star may take minutes to fix. The same assumption discovered in production may take weeks.

The chain exists to move learning earlier.

What makes it work with agents

The methodology was intentionally designed around the strengths and limitations of both humans and agents.

Agents excel at exhaustive research, codebase analysis, cross-referencing telemetry and feedback, drafting declarations, implementing against specifications, and verifying truth statements.

Humans excel at defining outcomes, understanding organizational priorities, applying domain expertise, evaluating trade-offs, and determining what great looks like.

The working model is collaborative. Agents research and draft. Stakeholders review, redirect, and add context that was never written down. Agents refine. The process repeats until the declaration accurately represents intent.

The declaration becomes precise enough for an agent to execute and understandable enough for a human to evaluate.

Changes flow through the declaration

When behavior changes, the change enters the declaration at the highest affected layer and cascades downward.

A new business outcome enters at the north star. A workflow change enters at flows. A technical decision enters at design.

The declaration changes first. Plans are generated for the delta. Implementation follows. Plans are removed.

This prevents one of the most common forms of organizational drift: code evolving independently of intent.

Scales to fit

Not every initiative requires the full chain.

A complex feature may require findings, north stars, flows, design, and plans. A well-understood enhancement may require findings and plans. A bug fix may require neither.

The test for every layer is simple: does it add clarity, or does it add ceremony? Skip ceremony. Preserve clarity.

Outcomes

While the methodology is still being rolled out across the organization, early applications have demonstrated measurable impact on delivery speed and implementation readiness.

For a new AI-powered profile insights feature that summarizes involvement and engagement data, engineering preparation and planning time was reduced from an estimated four to six weeks to approximately one week. By establishing a validated declaration before implementation began, the team spent less time clarifying intent and more time executing.

For a major Groups initiative, engineering originally estimated approximately nine months of delivery. Using the ODAD process to establish shared intent, identify existing capabilities, and reduce ambiguity before implementation, the feature was ultimately delivered in approximately three and a half months.

Additional outcomes include:

• Adoption across multiple engineering, product, and UX teams during the FY26 rollout
• Establishment of a shared vocabulary spanning Product, UX, QA, and Engineering
• Formalization of UX’s role as the authority responsible for validating findings, north stars, and flows against customer reality
• Creation of a delivery model designed for both human-led and agent-assisted software development
• Introduction of structured feedback mechanisms that allow the methodology to evolve through adoption rather than mandate

Reflection

The hardest part of the rollout was not defining the methodology. It was creating trust in the methodology.

Teams under delivery pressure naturally want to move directly to implementation. The recurring challenge was helping teams understand that the largest source of waste was often not in coding, testing, or deployment. It was in the ambiguity that existed before those activities began.

The most surprising lesson was that the largest gains did not come from faster implementation. They came from reducing uncertainty before implementation started. In both the AI profile insights initiative and the Groups project, the greatest acceleration occurred before engineering wrote meaningful amounts of code. Teams spent less time rediscovering requirements, resolving conflicting assumptions, and revisiting earlier decisions because intent had already been validated through the declaration.

Another lesson was that adoption metrics alone are misleading. Knowing how many teams are using a methodology tells you very little about whether it is helping them. A methodology that looks elegant on paper but creates friction in practice will eventually be abandoned. Establishing structured feedback loops between teams and leadership became just as important as teaching the process itself.

The principle at the centre of ODAD is simple: the declaration and the code must agree. When they do not, either the declaration is wrong or the implementation is. As AI continues to compress the cost of implementation, that principle becomes increasingly important. The long-term value of the methodology is not that it helps agents write software. It is that it forces organizations to become explicit about intent before software is written at all.