One Growing Brain for All Your AI Agents

I want a design decision to carry into every product we build. Cortex gives my connected agents the knowledge behind that decision, and our shared UI system gives them the components to implement it.

I own our frontend and design. When I explain what I want to AI eduarda, my chief of staff, she coordinates the work with our Design Manager and the agents building our products. I don’t want each agent to invent a different answer to a question we have already settled.

One product needs knowledge from the whole system

Cortex’s UI came from what we had standardized for Journeys. I built its UI/UX with my agents, using that shared foundation to shape how people find and edit knowledge, follow Dependencies and work through Issues.

A button in the Module editor needs to save the right decision. Its appearance and interaction also follow the shared button component. The surrounding form needs the right field behavior, and the page needs to work with our navigation on a phone as well as a desktop.

We keep that knowledge in Modules. A Module states what should be true about one part of the system and why. That includes our standards and values, not only product decisions, so an agent can work the way we work. The code shows what is true today. Keeping those two aligned is part of the work.

Dependencies connect a Module to the knowledge needed to understand it. When an agent flashes the relevant Module, Cortex brings that connected knowledge together. That is the SemDAG, our Semantic Directed Acyclic Graph.

I think of those connections as pathways through our brain for the work. Product knowledge leads to the shared design decisions and service contracts it needs. We can maintain a common decision once instead of copying it into separate instructions for each app.

My co-founder Mike built Cortex’s API, backend and MCP, which connects agents to Cortex. He builds the services API-first, so our interfaces can use the capabilities he has built. He also keeps the knowledge of how those services should work in Cortex.

When my agents work on Cortex’s interface, they can retrieve the relevant Modules he maintains alongside my design direction. That tells them how Modules and Issues should behave and how to use the existing API. I can focus on the experience I want, and my agents can build on his knowledge without me having to teach them the backend myself.

socra.design makes our shared design system visible. The knowledge explains our intent; the components give our agents a reusable implementation. Both have to stay useful as the products change.

What happens if I want our buttons more rounded?

If I say, “I want our buttons more rounded,” AI eduarda carries that intent to the Design Manager, who identifies the Module and shared component that govern those buttons.

The agents preserve the decision and its reason in the Module. Issues track the work needed to bring the shared component and affected products into line with that intent. The agents change the implementation, check its supported states and publish the release. They then update the affected products and inspect the buttons there.

A later agent can retrieve the decision; a product gets the changed appearance when it adopts the component release. The next product can start with both. If its agents find missing or outdated knowledge, I expect them to clarify the intent, update the right Module and track any implementation change in an Issue. What we learn can improve the foundation the next product uses.

The Cortex interface story in Meet AI eduarda follows this relationship from our Journeys foundation into Cortex and a shared correction carried back into Journeys. I supply direction and corrections as we work; my agents preserve the knowledge and keep it current.

Build this around your own work

Start with something you are building and a decision you care about. Tell your agent what should be true and why. Have it find the relevant Module in Cortex, or create one if that subject has no home yet.

Ask it what other knowledge is needed to understand that decision. A product may need your design rules and the service contract it calls. The agent connects those prerequisites as Dependencies, so a later flash brings them together. Have it reuse a teammate’s existing Modules when you have access. Your decisions can connect to knowledge someone else already maintains, just as my frontend work connects to Mike’s backend knowledge.

Then have the agent inspect the current work. Where the implementation differs from your intent, it should record the change needed in an Issue, do the authorized work and check the result. If that work reveals a better decision, have it update the knowledge and explain why. Finding different code does not by itself mean the intent should change.

Here is the direction I would give:

If your agent is not connected yet, set up Cortex with your agent. You supply the intent and judge the work. Your agent handles the knowledge and the changes needed to carry it forward.