The project fails in the first meeting, months before anyone notices. Someone wants an agent. The room agrees it is a good idea. Then the conversation drifts. One person is talking about which model to use. Another is talking about the prompt. A third is sketching the interface. A fourth wants to know what it will cost. Everyone is describing a different part of a thing nobody has defined, and because there is no shared picture of what an agent even is, the meeting ends with enthusiasm and no scope. The work that follows is improvisation dressed as engineering, and it stalls for reasons that look technical and are not.
The reasons are almost always scoping. The team built deep memory into an agent that answers one-shot questions and never needed it. They skipped evaluation entirely on an agent that makes decisions money depends on. They wired six integrations before confirming the agent could do the one thing the user actually asked for. Each of these is a choice that was never made deliberately, because there was no moment in the process where the choices were laid out and decided. The agent inherited its shape from whoever spoke loudest in the meeting, and the shape was wrong in ways that only surfaced after the build.
| What the team built | What the agent actually needed | The dimension nobody scored |
|---|---|---|
| Deep memory | One-shot answers, with nothing carried between turns | Memory |
| No evaluation at all | Decisions money depends on, checked before they land | Evaluation |
| Six integrations, wired first | The one thing the user asked for, confirmed working | Integrations |
Agent Redwood is the design framework that puts the choosing back where it belongs, before the build. It is a twelve-dimension assessment run as a working session. You score each dimension for the agent you are designing, rank which dimensions actually matter for this use case, and decide how far to invest in each one for the first version. The session produces a one-page blueprint, and the blueprint maps directly to the architecture and implementation choices that follow. The whole point is to turn the vague enthusiasm of that first meeting into a concrete, shippable v1 that everyone in the room can see.
The name carries the idea. A redwood is the same kind of tree whether it is a seedling or three hundred feet tall, and the difference between the two is how far each part was allowed to grow. An agent works the same way. The dimensions are fixed. What changes from one agent to the next is how far you grow each one, and that is the decision the framework forces you to make on purpose rather than by accident.
The twelve dimensions, in no particular order
Twelve dimensions, named precisely, each one a question about the agent you are about to build. They come in no fixed order because the order that matters is the one you assign during scoring, not a canonical ranking that holds for every agent. What is deep for a support-triage agent is shallow for a research copilot, and the framework exists to surface exactly that difference.
Personality is the stance the agent takes: its tone, its verbosity, its risk posture, how it carries itself with a user. Planning is how it decomposes a goal into steps, from a single fixed sequence to a live tree it revises as it goes. Mission is the standing objective, the one thing the agent exists to do that every action answers to. Constraints are the rules it must not break, the hard boundaries on what it is allowed to say and do. These first four set what the agent is and what it is for, before any question of how it works.
Memory is what the agent retains and for how long, from nothing between turns to a durable record of everything it has seen. Evaluation is how it judges its own output, the rubric it scores against before it commits to an answer. Tools are the functions it can call, the actions it can take in the world beyond producing text. Awareness is the agent's model of its own situation: what it is doing right now, what it can do, where it is uncertain, what has recently failed.
The reward model is the signal the agent optimizes toward, the preference structure that defines a good outcome from a bad one. Metadata is the bookkeeping that makes the rest auditable: who produced what, when, and with what confidence. Strategy is the longer arc above any single plan, the pattern of behavior that serves the mission across many interactions rather than one. Integrations are the wires to the outside, the systems through which events reach the agent and through which its actions take effect.
You cannot min-max everything
The central discipline of Agent Redwood is the one people most want to skip. You cannot make all twelve dimensions excellent at once. Time, attention, and budget are finite, and an agent that tries to be deep on every dimension ships late, costs too much, and is harder to reason about than one that is deep where it matters and shallow where it does not. The decision the framework forces is where to spend the depth, and the answer is different for every agent.
Consider a support-triage agent whose job is to read an incoming ticket, classify it, and route it. Its constraints are load-bearing, because misrouting a security incident to billing is a real cost. Its evaluation matters, because a wrong classification needs to be caught. Its memory can be shallow, because each ticket is largely independent. It needs almost no strategy, because there is no long arc, only a stream of independent decisions. A reward model is probably overkill for a first version. Scored deliberately, this agent is deep on four dimensions and thin on the rest, and that thinness is correct, and it was chosen deliberately.
Now consider an internal research copilot that works alongside an analyst across a week-long investigation. Its memory is everything, because the value is in what it accumulated yesterday. Its awareness matters, because it has to know what it has and has not checked. Its strategy is real, because the work has an arc that spans many sessions. Its personality can be plain, and its constraints, while present, are lighter, because the cost of an imperfect answer is a second look rather than a misrouted incident. The same twelve dimensions, a completely different depth profile, and the difference is the entire design.
Scoring forces the conversation that the first meeting never had. When the room rates memory a nine for one agent and a two for another, the disagreement that used to hide in vague enthusiasm comes into the open and gets resolved. The score works as a forcing function for a decision, and the decision is what the build inherits.
The working session and the dial-in
Agent Redwood runs as a questionnaire, and the questionnaire is adjustable. You dial in how intensive you want it to be, by how many questions you are willing to answer or how much effort you are willing to spend. There are presets, small, medium, and large, and the recommendation is to do the large one. You want to let the system drill you, because the more context you give it about the problem, the world around the problem, and the full story of the person who has it, the better the thing it designs for you. A thin questionnaire produces a thin blueprint. A thorough one extracts the insights that would otherwise have surfaced as expensive surprises deep into the build.
The session does not begin with the twelve dimensions. It begins with value. Before scoring a single dimension, the framework asks how the agent helps someone make money, save money, or mitigate risk. Ideally all three are on the table, and you brainstorm and then narrow down based on which carries the most value. This is the rail the rest of the session runs on, because a dimension only earns depth if depth on that dimension serves the value. Investing in a sophisticated reward model on an agent whose value is purely saving time is depth spent in the wrong place, and starting from value is what catches that.
From value, the session moves to the shape of the decision the agent makes, and here the framework leans on Professor Warren Powell's unified framework for sequential decisions. Most people reach for the most complicated policy class first. Powell names four: policy function approximations, cost function approximations, value function approximations, and direct lookahead approximations. The instinct is to start at the sophisticated end, with a value function or a direct lookahead, when the vast majority of the time a simple policy function approximation is all the agent needs. You start simple because a simple policy gets you a ballpark estimate that tells you whether you are even pointed at the right problem, and you add complexity only as the value substantiates it. The same discipline that says you cannot min-max all twelve dimensions says you do not reach for the hardest decision machinery until the problem has earned it.
With value framed and the decision shape understood, the twelve dimensions get scored and ranked, and the output is the one-page blueprint. One page is the constraint that makes it useful. A blueprint that runs to forty pages is a specification nobody reads and a decision nobody can hold in their head. One page forces the depth choices to be explicit and legible: here is what we are investing in, here is what we are deliberately keeping thin, here is the v1 we agreed to build. Everyone from the founder to the engineer can read it and see the same agent.
From blueprint to build
The blueprint is worth building only because it maps onto real implementation choices. A depth score on a dimension is a directive to the architecture. When memory scores high, the build provisions a durable store and the retrieval path that reads from it; when it scores low, memory is a turn-scoped buffer and nothing more. When evaluation scores high, the build adds the scoring pass and the rubric it grades against; when it scores low, the agent returns its first answer. The blueprint is the bridge between the design session and the system, and the depth profile is the thing that crosses it.
The framework lives next to the rest of the stack rather than in isolation. The decision shape from Powell tells you which orchestration primitives the build reaches for, from a single routing function up to the planning and lookahead structures the harder policy classes require. The tools dimension tells you which functions the agent is given and how their reliability is tracked. The integrations dimension tells you which external systems get wired and in what order. Because the blueprint is grounded in a real, current knowledge base of how these technologies actually behave, the agent it designs is built against patterns that work in production rather than against a model's stale recollection of how an API used to look.
| Dimension | What the build inherits from its score |
|---|---|
| Memory | A high score provisions a durable store and the retrieval path that reads from it. A low score leaves a turn-scoped buffer. |
| Evaluation | A high score adds the scoring pass and the rubric it grades against. A low score returns the first answer. |
| Decision shape | Which orchestration primitives the build reaches for, from a single routing function up to planning and lookahead structures. |
| Tools | Which functions the agent is given, and how their reliability is tracked. |
| Integrations | Which external systems get wired, and in what order. |
This is also where the framework earns its keep against the failure it was built to prevent. The support-triage agent that scored memory a two does not get a vector store nobody needed. The research copilot that scored strategy an eight does not ship without the long-arc layer that is the entire point. The choices that used to be made by accident, by whoever spoke loudest, are now made on the page, in the open, before a line of code commits the team to them.
What it costs to skip the scoping
The case for the session is clearest in its absence. Without it, the first meeting's drift becomes the project's shape. The team argues in circles, because there is no structure to resolve the argument, and the disagreements that should have been settled in an hour stretch across weeks. Features get built on the strength of whoever advocated for them rather than on whether they serve the value, and the low-leverage ideas survive because nothing in the process kills them. The result is the slide-deck agent: a thing that demos well and was never scoped to ship, that looks impressive until someone tries to put it in front of a real user with a real problem.
The session collapses that. Across many projects the pattern repeats: weeks of fuzzy debate compress into a few structured sessions. Teams align on a concrete v1, kill the low-leverage ideas early, and ship simpler agents that hold up because they match the constraints they actually have. The compression is what happens when the decisions that were going to get made anyway, badly and late, get made deliberately and early instead. The argument still happens. It happens once, on the page, where it can be resolved, rather than continuously, in the build, where it cannot.
A repeatable ritual, not a one-time artifact
The deepest value of Agent Redwood is that it turns "let us experiment with AI" into a repeatable design ritual. The first time a team runs it, the win is a scoped v1. By the third time, the win is bigger: the team has a common mental model for what they are building, a shared language that a founder and an engineer can both speak, and a process they trust enough to run on every new agent without relitigating what an agent is. The framework stops being a worksheet and becomes how the team thinks.
That common model is what was missing in the first meeting. The four people talking past each other were not wrong about their pieces. The model was right, the prompt mattered, the interface was real, the cost was a fair question. They had no frame that held all of it at once, no way to see that they were each describing one dimension of a twelve-dimension thing. Agent Redwood is that frame. It does not make the hard choices for you. It makes them visible, puts them in order, and forces them to be decided before the build inherits them by default.
An agent is twelve dimensions you grow on purpose. Score them deliberately, rank them for the problem in front of you, invest the depth where the value lives, and write the one page everyone can read. The agents that ship are the ones that were scoped before they were built. The agents that stall are the ones that were built before anyone decided what they were. The next essay turns from designing a single agent to running many of them in production, and the blueprint you scoped here is what each of them is built from.
| Dimension | The question it scopes | Deep when |
|---|---|---|
| Personality | What stance, tone, and risk posture? | The agent is user-facing and the register carries trust. |
| Planning | How is a goal decomposed into steps? | Tasks are multi-step and the path is not fixed. |
| Mission | What single objective does everything answer to? | Always. The mission is the rail and stays deep. |
| Constraints | What must it never do? | A wrong action carries real cost. |
| Memory | What is retained, and for how long? | Value accumulates across turns or sessions. |
| Evaluation | How does it judge its own output? | Wrong answers must be caught before they ship. |
| Tools | What actions can it take? | The work requires acting, not only answering. |
| Awareness | What is its model of its own situation? | The agent must track what it has and has not done. |
| Reward model | What does it optimize toward? | Outcomes are graded and the preference is learnable. |
| Metadata | What makes the work auditable? | Provenance and confidence are load-bearing. |
| Strategy | What is the arc above any single plan? | Behavior spans many interactions toward one end. |
| Integrations | What outside systems connect? | Events and actions cross the agent's boundary. |
END OF ESSAY 07 OF 14 · THE GIGA LIBRARY · WIKIDESIGNCO