Company brains, Cursor for video, and a four-agent social team.

The Brain Factory: one living knowledge graph per company

Isaiah Zimmerman

Graph build cost fell from roughly $600 and four hours on a frontier model to $40–$60, with up to 40% more document density and relationships

The problemRoughly 20 million US mid-market businesses run on a million to fifty million a year and have nobody on the team who can be the technical implementation layer — so enterprise-grade context is out of reach, and the DIY answer is a flat file brain that only traverses one direction and cannot tell you what is still true.

Isaiah and his co-founder Christopher Schenk build company brains for mid-market businesses. His argument is that context engineering comes down to understanding how memory systems work, and that the common advice — set up a markdown knowledge graph, put it in a notes app, search it globally — produces something that is not living. It is flat-path: it traverses one direction and never crosses the multiple dimensions of relationship between your data. What changed is cost. A few months ago, at one of these same events, he sat with his laptop open backfilling one of his own internal graphs; on a frontier model that run cost about six hundred dollars and burned four hours. Today the same graph costs forty to sixty dollars to build, and document density and the number of relationships between documents have gone up by as much as forty percent. That collapse in price is what moved company brains from bespoke consulting to something the platform can produce for almost nothing. The architecture underneath is a true graph RAG retrieval system — semantic search plus BM25, a chunking layer, a vector layer, and an agent layer on top — and the piece Isaiah stresses most is temporal evidence. Time-bound weighting is what stops the brain from pulling something from March, presenting it as current, and telling you to call a person who was let go or restart a campaign you killed. His framing for the whole category: the company brain is not the product, it is the enablement layer for the agent layer. Plenty of people in the room have already built a second brain and handed it to an agent — the open question is what you do with it next.

You are helping me design a company brain that my AI agents will use as their shared context. Do not write any code yet.

First, interview me about my business: what systems hold our real decisions (calls, email, chat, CRM, finance, docs), how many people are on the team, and how fast our facts change.

Then produce:
1. An inventory of every source worth ingesting, ranked by how much decision-context it holds versus how hard it is to connect.
2. A recommended storage and retrieval design that I can self-host and export, and that I can point at any model provider — explain where semantic search, keyword search, and graph relationships each earn their place for MY data.
3. A recency policy: for each source, how stale is too stale, and what should trigger a refresh.
4. The standing instruction to put in my agent's rules file so it always checks the graph for context and then confirms against live tools before acting.
5. An access matrix: which agents and which people should see which parts, and what should never be ingested at all.

Flag anything that would need to stay on local hardware for compliance reasons, and tell me what you would build first if I only had one week.

Takeaway Do not think of the company brain as something the model providers will eventually absorb. It is an asset you need for yourself, and it happens to work with any language model.

~12x faster content pipeline, running on cheap Gemini Flash-class models rather than a frontier model

The problemVideo editing was the bottleneck on content marketing. The real drudgery was not cutting bad takes — it was placing a graphic on screen from here to here, by hand, every single time.

Josh spent six years as a content creator and coach before his best friend started teaching him to code; five or six months ago he went all in and built a video editing application. The pitch is a chat-driven editor, and he is candid that the first two things it does — chat-based cuts, then captions — are what everybody has. Where it separates is that you can ask it to restyle the captions, and it goes and reads the emotional payload of each individual word in the transcript, decides whether that word is positive, negative or an emphasis beat, and styles it accordingly. From there you can talk to it about graphics: remove these captions, add a supply and demand diagram, make it for YouTube with big bold graphics and no small details, give the background a frosted-glass transparency. It codes that, measures what it produced, screenshots its own output, notices when it did a bad job, and tries again. The framing underneath is the part worth stealing. Josh calls the number one problem of AI the fact that ninety percent of it is the best thing you have ever seen and ten percent is unusable — and therefore all of it is unusable. His answer is that the solution is not to make AI perfect, it is to make AI capable of adjusting. He is an obsessive student of learning theory, with about two million followers writing about it, and he sees agents mirroring human development: it is not about getting it right, it is about being able to get it right over time. That belief shows up in his cost structure. Frame Controller runs on cheap, fast, deliberately unimpressive models rather than a frontier model, and it works because of the training around it — give an agent the ability to fetch the instruction it needs when it needs it, the ability to check its own work afterwards, and guidelines to check against, and it will do good work regardless of which model is behind it.

I want to move a repetitive production workflow onto cheap, fast models instead of a frontier model, and I want it to be reliable.

My workflow is: [DESCRIBE IT — e.g. editing talking-head video, producing carousels, formatting reports].

Help me do this in the following order:
1. Break the workflow into individual actions. For each one, say whether it is mechanical drudgery (automate first) or genuine craft (keep human).
2. For each mechanical action, write the instruction set an agent would need — including how it fetches the context it needs at the moment it needs it.
3. Design a self-check for each action: what should the agent measure or screenshot to grade its own output, and what does the brief look like that it grades against?
4. Give me an explicit guidelines document the agent can check against.
5. Tell me how to test this: I will run it on a frontier model first, then on a deliberately weak model. Tell me what failure modes to watch for and how to read each one as a gap in my instructions rather than a limit of the model.
6. Identify where I must keep granular manual control, so one bad output does not make the whole result unusable.

Assume I would rather spend an hour improving instructions than ten times as much per run on a bigger model.

Takeaway The solution isn't really to make AI perfect. The solution is to make AI capable of adjusting.

Four agents, twenty posts a week, one hour of recording

Oscar Hidalgo

20+ posts per week, with the process going from roughly 8 hours a week to 1 hour of recording

The problemOscar runs an HVAC company and an AI consultancy, and between the two businesses and a young family he had zero time for social media — which the consulting business needed in order to grow.

Oscar is the CEO of an HVAC company who taught himself AI on YouTube, started an AI consultancy called Vindex Consulting for small and mid-sized service businesses, and joined the Agentic Society as its Hermes trainer. He is emphatic that he is not a technical founder — he has done operations for about ten years, and he approaches AI agents exactly the way he approaches hiring people: think about the SOP, think about the process, think about what the job description would be, then brainstorm it with Claude until something is built. He had been accumulating one agent per small task, and spent the last month consolidating them into the main roles at the top of his company: a marketing agent, an operations agent, a developer agent. The build he presented is a work graph for social media, where each agent owns one stage and hands off to the next. Eve is his integrator — the concept borrowed from Traction — and she is the only agent he talks to. She holds the most context, reviews other agents' output, and assigns the Kanban tasks, which means he never has to chase individual agents or remember their names. The run fires Sunday night: pull last week's, month's and year's analytics from Blotato, QA the numbers, hand off to Becca the marketing agent to research what the AI discourse is actually about this week using the X and Gemini APIs, and come back with topics for three short-form videos and a set of carousels. A skill trained on all of Oscar's emails and communications then quality-controls the output against his real voice before it reaches him in Notion. He records, his agents pick the video up out of Google Drive through browser automation on a virtual Linux machine, edit it in a web-based tool, put it back, and Becca writes platform-specific copy — short for TikTok, long for LinkedIn — plus the hashtag research and the carousels. The only thing left on Oscar is recording and posting stories.

Act as my operations designer. I want to hand a recurring content process to a small team of AI agents, and I want to design it the way I would design a team of people.

My situation: [YOUR BUSINESS], and the recurring output I need is [e.g. three short videos and two carousels per week].

Work in this order:
1. Start from the finished outcome and work backwards. If I were hiring humans for this, what roles would exist, and what would each one's job description and success measure be?
2. Turn that into a work graph: the stages, who owns each, and exactly what gets handed from one stage to the next. Describe it so I can draw it, and flag where a handoff is likely to break.
3. Recommend one integrator agent as my single point of contact. Define what context it holds, what it reviews, and how it assigns work.
4. For each specialist, give me the narrowest useful skill set and tool list — one agent, one job.
5. Tell me where in the graph my own performance data should enter, so topic and priority decisions are grounded rather than invented.
6. Design a voice quality gate: what should I train it on, and what should it check before output reaches me?
7. Tell me which tools need to be web-based because agents will operate them through browser automation, and which steps should stay manual because they are genuinely mine.

End with the smallest version I could run this coming week, and the one recursive improvement to add after that.

Takeaway I go about AI agents the same way I go about hiring employees. I think about SOPs, I think about processes, and I think about what the job description would be.