Your team adopts AI, and suddenly everyone has a second job: explaining the product to it. The spec is in a ticket, the reason behind it is buried in a customer call, and the designer is pasting the same component rules into another conversation. Getting AI ready to work can take almost as much effort as doing the work yourself.
I’m hearing this from the B2B SaaS teams we work with at The Design Project. We’ve been bringing that scattered knowledge into something we call the product brain: a maintained set of project context, decisions, and working rules that AI can consult before it starts building. This is a practical application of context engineering, the broader discipline of organizing the information available to an AI agent.
On one customer project, I used that brain to create an activity notification component in Figma from an existing feature spec. It took about eight minutes and still needed my review. What interested me was how the agent followed the project’s component foundations, naming conventions, and workflow without me explaining each one again.
Table of contents
- What is context engineering for product teams?
- What belongs in a product brain?
- How we built a Figma component from product context
- How to build your own product brain
- Where human approval belongs in design-to-engineering handoff
- How to keep AI project memory current
What is context engineering for product teams?
Context engineering for product teams is the practice of organizing and maintaining the information AI needs to do product work: customer needs, approved decisions, feature requirements, design-system rules, and team responsibilities. A product brain makes that information retrievable, so an agent can work from the team’s current understanding and identify what still needs clarification.
The brain is our practical way of applying this to ongoing client work. It can live in the product repository or in a separate repository for design, which is what we used on this project. The underlying documents stay readable by people and usable across AI tools.
There’s a broader technical discipline behind this. In its September 2025 guide, Anthropic describes context engineering as curating the information available to a model, with attention to the limits of its context window. For a product team, that means deciding which information an agent needs for the task and giving it a reliable way to find it.
Writing “create the activity component” can be a perfectly reasonable request once the agent knows which spec defines it, where the shared components live, and who approves the result. Without that background, even a detailed prompt leaves a lot of room for assumptions.
What belongs in a product brain?
A useful product brain separates current decisions from the conversations that produced them. Meeting transcripts preserve history. Approved decision records and feature documents tell the team what applies now. A short current-context page points to active work and unresolved questions.
In our setup, the context includes the company’s vision, business and technical constraints, stakeholders, feature specs, design rules, and communication guidelines. We also keep the meeting history and explorations that explain how we got there.
| Part of the brain | What it helps the agent understand |
|---|---|
| Start-here document | What the company does, who the product serves, and where to begin |
| Context principles | How to read, organize, and maintain project knowledge |
| Working rules | How design work moves through review and engineering handoff |
| Current context | Active priorities, recent changes, and open questions |
| Decisions and feature specs | What has been agreed, why, and what the feature needs to do |
| Meetings and explorations | Supporting history, research, and ideas that may still be provisional |
| Communication guidelines | How to write useful project updates for the people involved |
That last piece is easy to overlook. I used the same context to ask for a short update about the component we had built. The communication guidelines described the tone, recap, and next steps, so the draft had a structure tied to how that team works. I still checked whether the agent had actually consulted the right guidance.
Our agentic design system guide covers the repository instructions and visual rules in more detail. The product brain extends that context to the decisions and people around the design work.
How we built a Figma component from product context
The customer example started with spec 88, which covered multiple transcript uploads without an integration. We had developed the scope from calls and conversations with the team. One part of that work was an activity notification component, and I asked the agent to create it in the components section of our Figma file.
The project and people were anonymized for the demonstration, but the workflow came from real customer work. The agent could consult the feature spec, the documented Figma workflow, and a component skill stored in the repository. That gave it a route from the requirement to the existing design foundations.
As it worked, the agent checked the component area, identified reusable components, and looked for existing tokens and styles. The resulting component followed the project’s atomic naming convention and the foundations we had defined for colors and patterns.
What the eight-minute result actually tells us
The run took about eight minutes, longer than I expected. I also wanted to make some design tweaks before taking it further, so this was a component ready for inspection and refinement. The result was a generated Figma component that I could refine before taking it toward implementation.
What we could see was a useful connection between the spec and the component library. The agent had enough project context to work within the system, and I could spend my attention reviewing its output. That is the part I want teams to notice when they try this themselves.
How to build your own product brain
You can use the same pieces from this customer workflow to get started. The five steps below organize the setup into a practical sequence: establish the project context, define the working rules, and try them on a feature with a clear spec. Expand the structure as repeated use shows what the team needs.
- Write a short project entry point.
- Separate source material from approved decisions.
- Document the design workflow and its owners.
- Connect a feature spec to the relevant components.
- Run one task and review how the agent used the context.
1. Write a short project entry point
Explain what the company does, who the users are, the product’s current state, and the constraints that affect decisions. Link to deeper material such as the product vision, stakeholder information, or business model canvas when it helps explain the work.
Our customer context came from early conversations about the business and product. That matters because the agent needs to understand why a feature exists before making choices about how it should behave.
2. Separate source material from approved decisions
Give incoming material a temporary home, such as an inbox. Meeting records belong with meetings; research and unfinished ideas belong with explorations. When the team reaches a durable conclusion, put it into the relevant decision or feature document and link back to the supporting history.
A transcript can contain an idea, a disagreement, and a later resolution. Treating all three as equally current makes the agent’s job harder. Have someone verify which conclusion should guide the next task.
3. Document the design workflow and its owners
Describe where work in progress lives, how it becomes ready for review, and who can move approved work into ready for dev. Write down the checks that matter to your team, including component reuse, naming, design tokens, and exact frame links.
We also define what each tool owns. Figma carries visual decisions, Linear carries scope, and Slack carries short notifications. The brain connects those responsibilities so a message in Slack does not accidentally become the only record of an important design decision.
4. Connect a feature spec to the relevant components
Choose a bounded task, such as one activity notification. Give the agent the approved requirements and point it toward the component library, design foundations, and task-specific skill. Make unresolved behavior explicit so the agent knows where a person needs to decide.
Figma’s MCP documentation describes how its server makes design context available to AI tools. Your project documents still need to explain which designs are approved and which conventions apply. Our guide to agent skills for design systems explains how we package repeatable component instructions.
5. Run one task and review how the agent used the context
Check the output and the path the agent took to produce it. Did it read the right spec? Did it reuse existing components? Did it stop at the correct review stage? A polished-looking component can still be based on an outdated requirement.
Keep a person involved in checking the context as you use it. In our setup, that means reading what the agent has captured, making sure it makes sense, and keeping the working rules current as the project changes.
Where human approval belongs in design-to-engineering handoff
Human approval belongs at the transition from a proposed design to an agreed implementation target. In our customer workflow, the designer owns moving work into ready for dev, and the engineer’s explicit approval is required before that handoff. The agent can prepare the work and check the documented conditions while those people retain their responsibilities.
The Figma file has separate areas for work in progress, ready to review, ready for dev, current designs, and components. The written rules tell engineering and agents to use the approved frame in ready for dev and consult the shared component library.
Before that transition, the workflow calls for these checks:
- Confirm the design uses shared component instances and the intended atomic naming.
- Confirm it uses the project’s design tokens rather than local substitutes.
- Add the exact Figma frame and component links to the Linear task.
- Obtain the required engineering approval before the designer moves the frame.
The scope of delivery also needs to be explicit. For this customer, the default deliverable was Figma, with a frontend pull request included only when the task or agreement called for an initial implementation. Other engagements can define a different scope in their working rules.
The ownership is explicit: the designer moves approved work into ready for dev, and the engineer approves the handoff. The agent’s instructions should reflect those responsibilities throughout the task.
How to keep AI project memory current
Keep AI project memory useful by reviewing new information, updating the document that owns each decision, and keeping the current-context page short enough to navigate. Preserve the history behind a change through links, and make pending questions visible. Someone on the team needs to own that maintenance.
We use an agent to collect recent meeting context, and the system supports sorting incoming material into the appropriate place. I still want a person reading what gets promoted into durable memory. An automatically generated summary can sound convincing while missing the point of a conversation.
Keep the current-context page manageable
Our current-context document tracks active work and recent changes. It can get long, and we are still refining how to simplify it and archive older material. The practical goal is to help the next session recover the current state quickly, with links to the detail it needs.
The principle we keep coming back to is “small and current beats large and stale.” A maintained decision and a link to its source are easier to use than several copied summaries that slowly disagree with each other.
Let repeated use guide what you add
You do not need to produce a polished summary for every meeting or build every possible automation before starting. Begin with the context your team repeatedly has to explain, then see whether the agent can find it and use it correctly.
That is how we are developing the brain at TDP: through customer work, component creation, review, and the gaps those tasks expose. The more clearly we document the decisions around the design, the more useful the next AI session can become.
If your team is spending too much time re-explaining the product to AI, talk to TDP about setting up a product brain for your workflow.
