The team whose reasoning is searchable
Ricardo Argüello — May 10, 2026
CEO & Founder
General summary
Aakash Gupta published two posts this week, May 8 and May 9, that crossed 89K views combined and named a pattern most operators have been groping at for years. Team OS, three layers: shared context, shared queries, shared discipline. Hannah Stulberg at DoorDash built it. Garry Tan launched GBrain the same Friday from the Y Combinator chair making the same argument. The math behind the urgency is brutal. Ten context questions per person per day at ten minutes each is eight hours per person per week, twenty percent of every working hour. In a fifty-person company that is four hundred hours per week, one engineer-year burned every two months.
- Aakash Gupta documented four independent implementations (Hannah Stulberg at DoorDash, Dave Killeen at Pendo, Gabor Meyer at Google, Carl Vellotti building solo) that all converged on the same architecture
- The three layers: shared context (what feeds the system), shared queries (how the team asks it questions), shared discipline (how the system stays alive)
- 47% of companies call institutional knowledge loss their top offboarding problem; new hires take 6 to 7 months to feel productive
- Garry Tan, CEO of Y Combinator, launched GBrain the same Friday with the same thesis: the future belongs to people who build compounding AI systems, not to people who use centralized corporate AI tools
- At IQ Source we have been running this exact architecture before Aakash named it: we ingest call transcripts, propagate open action items, surface customer decisions from three months ago in seconds
Picture your best PM making an important architectural call in a Slack thread on a Tuesday afternoon. Five messages later someone makes a joke about lunch and the thread sinks. Three months go by. A new engineer asks why X was chosen over Y. If the thread is the only record, two bad things happen: she reopens the decision without context, or she pings your PM, breaks his day, and waits. Multiplied across the team, that wait eats one of every five hours your investor is paying for. Team OS is the place where the decision lives in a format the new engineer or an AI agent can query in fifteen seconds without bothering anyone.
AI-generated summary
Something happened this week worth a closer read. On Thursday, Aakash Gupta published the case of Hannah Stulberg, a PM at DoorDash who had quietly built the cleanest implementation of team memory I have seen in a year. On Friday he published the math: a fifty-person company burns 400 hours a week rediscovering decisions it already made. One engineer-year every two months. Twenty percent of every working hour. The two posts crossed 89K views in 36 hours and pulled in a comment chorus worth reading in full.
The IQ Source thesis here is direct. When AI compresses the build layer, the team that wins is the one whose past reasoning can be queried in fifteen seconds. By a new hire or by an agent. It is the same requirement. The team that does not have it pays the 20% tax forever, whether it shows up in the P&L or not.
And what happened on Aakash’s Thursday is that someone finally named the pattern. He called it Team OS. At IQ Source we have been running exactly this architecture from before it had a name. Today I want to show you what is inside it and why this Friday is the Friday your leadership team has to look at.
The math nobody runs
Three numbers worth carrying into your next operations meeting.
47% of companies call the loss of institutional knowledge their number-one problem when someone leaves. Not the cost of replacement. Not the cost of the search. The loss of what the person took with them.
New hires take 6 to 7 months to feel productive. Only 12% of employees say their company onboards them well. The other 88% pay that cost and it does not show up anywhere in the budget.
10 context questions per person per day. At 10 minutes each, between the Slack ping, the wait, the answer, and the context switch back to what you were doing, that is 8 hours a week. The fifth working hour of every person on your team is spent rediscovering what the team already decided. In a 50-person company that is 400 hours per week. A full engineer-year burned every two months answering “why did we choose X over Y” from threads that scrolled away three weeks ago.
That math does not appear on the board deck. The reason is simple: nobody measures it. The lost hour does not show up as a line item. It shows up as slow velocity, as the new hire who takes forever to ramp, as the decision that gets relitigated in the next meeting.
The comment from Tech Odyssey under Aakash’s post captures the shift now happening: agent memory and team memory are converging. Both fail for the same reason. Past reasoning exists somewhere but cannot be retrieved at the point of action. Whatever fixes one fixes the other.
The three layers
The architecture Aakash documented has three layers. Each one solves a different slice of the 20% tax.
Layer 1 — Shared context. A folder where the team writes things down. Product decisions, customer call summaries, analytics queries someone wrote at 2 a.m., architectural debates from the offsite. The structure is not the interesting part. The interesting part is that there is one place everyone knows to deposit the context. A CLAUDE.md in the root acts as the routing table: it tells the agent (or the human) what kind of question lives in which folder. With that one file, the system knows where to look before it reads anything.
Layer 2 — Shared queries. This is where the team asks. The difference between this and a traditional wiki is that the question is asked in natural language and the answer synthesizes whatever lives in the folder. It is the difference between “search Confluence” and “ask a colleague who read all of Confluence last night.” Hannah Stulberg’s case is the canonical example. A new engineer needed context on a customer decision from three months back. Instead of pinging Hannah and waiting, she opened the repo, asked in English, got the full reasoning in fifteen seconds. Hannah was not online. Did not need to be.
Layer 3 — Shared discipline. This is the layer most implementations skip and the layer that kills them when they skip it. The rule is one sentence: the feature does not ship until the repo is updated. The decision is not considered taken until it is written in the format the agent and the next person can query. Without that rule, the first two layers gather dust in six weeks. With it, the system stays alive on its own, because every person on the team feeds it the moment they make a decision.
The three together are what made Hannah’s repo answer the engineer’s 2 a.m. question without Hannah. Most teams try Layer 2 first because it is the visible one. But without 3, Layer 2 atrophies, and without 1, Layer 2 has nothing to read.
What we already run at IQ Source
Let me show the system from the use, not from the architecture.
It starts on the first discovery call. The transcript is ingested in the moment, no one copies it. From there the system pulls the open action items, what we promised to do, the open questions, the next steps, and pins them against that client. If we open a project later, those same items propagate on their own to the project tracker. And when somebody on the team needs to prepare a proposal or quote a project, they ask the system in natural language: “what do we know about this prospect,” “what price did we quote in February to a similarly sized company,” “what was the last handoff with this client.” The answer comes back with citations to the original source for each fact. Monday’s call becomes team memory by Monday afternoon, with no manual step in between.
That is Layer 1 feeding itself and Layer 2 being queried. The open action items are the decision log. The propagation to the project is the mechanism that gets the decision to the place where it will be executed. The natural-language query is the interface anyone on the team can use without training.
Layer 3 is the operating rule. No proposal is quoted, no client is closed, no handoff is considered clean if the corresponding context did not get written into the place the system can recover it from. It is not a guideline. It is the precondition for the next person, or the next agent, not having to reconstruct the context from scratch.
The concrete result: decisions from a client we worked with last quarter are fifteen seconds away from anyone on the team. A new proposal gets prepared with five years of precedent in view, not with the memory of whoever was on Monday’s call. When I take a three-day trip, the handoffs keep happening because the system knows where the open items go.
This is not theory. It is what we covered in March with the Dave Killeen case at Pendo, scaled one floor up. Killeen’s personal system, which is one of the four cases Aakash documented, automates him. Team OS automates the team. The difference is that the first one dies the day Killeen leaves. The second one survives turnover, vacations, and the simple fact that no human remembers everything.
Why AI Maestro and Tech Partner land here
I have spent 36 years in computing. I started in 1990 at age 15 on a Commodore 64. The institutional-knowledge problem is not new. What is new is that the cure can now be started in a weekend instead of a quarter. The old version needed Confluence, a knowledge-management team, taxonomies, tags, and six months to ramp. The new version is a Markdown folder, a routing CLAUDE.md, the first set of triggers, and a rule that nothing ships until the repo is updated. A team of three can stand the skeleton up in two days.
The skeleton is not the system, though. We have been tuning the IQ Source brain every day for the last month and we are still tuning. The folder structure we picked in week one did not anticipate half of what the team actually asks the system. The triggers we set up at the start fell short when the second client came in and we had to separate active-project items from prospect items. The routing CLAUDE.md has been rewritten three times because every new question the team tries reveals a gap in how the information is organized. That is real, recurring work that does not end. The difference from Confluence is that each adjustment shows up in the quality of the next answer the same day, not next quarter.
For B2B software companies in Latin America, Team OS is not a side project. It is the foundation under the two services we sell. AI Maestro is the version we install for the client’s team, where we govern how the calls get ingested, how the decision logs get written, how the discipline stays in place, and how we audit what the agent does with the memory. The audit question is not “does your team use Claude.” It is: if I call your best PM and ask for a decision from February, how long until she finds it written down?
For software companies whose product needs to keep getting built while this gets installed, Tech Partner is the other half. The three layers live inside the development process. Each PR closes when the technical decision that motivated it gets written. Each release is anchored to a log the next team can read. Each handoff between IQ Source and the client team passes through the repo, not through a calendar invite. It is the workflow moat I covered in April, made operational. The runtime commoditizing does not mean your workflow is legible. It means only that the cost of making it legible has dropped.
The convergence this week was real. Aakash on Thursday and Friday. Hannah Stulberg in the May 8 Substack. Garry Tan, CEO of Y Combinator, launching GBrain the same Friday with the thesis that the future belongs to those who build compounding AI systems, not to those who use centralized corporate tools. Four microphones saying the same thing in one week without coordination. That usually means the pattern is real.
As Marcel Velica caught in the comments: most productivity loss in teams is not execution, it is the repeated reconstruction of context that never got captured into a shared system. What changes now is not that the problem exists. It is that you have the option of not paying for it anymore.
Five questions for Monday’s leadership meeting
Start with the most uncomfortable one: where is the most important decision your team made this quarter actually written down? When the only answer that comes back starts with “in someone’s head” or “somewhere in a Slack thread,” the system does not exist. The test is brutally simple. Either you can leave the meeting with a file path, a date, and an author, or you cannot.
The second one needs to be looked at cold. A new hire walks in tomorrow morning. She needs context on a decision from February. How long does it take her to find it without interrupting anyone? When the honest answer is “she can’t,” the onboarding cost stops being measured in months. It starts being measured in interruptions per day for six months running.
Third question, and this one is for the board more than the team. Your most experienced PM resigns this Friday. What walks out with her? If the answer is “what she had in her head,” you have a collection of talented individuals. If the answer is “nothing the repo doesn’t already have,” you have a company.
The fourth question is where most of us fail. Who, by name, owns keeping the team repo alive? Not “everyone.” Not “the team.” A single person, with hours blocked on their calendar, with the authority to send a feature back to backlog if it did not update the corresponding decision. Without that figure, Layer 3 stops existing and the other two atrophy within six weeks.
And the fifth is the final test. When an AI agent in your company tries to answer the next customer question, what it finds defines the quality of the answer. Not the model. Not the prompt. What your team wrote down yesterday.
If the answers to all five are solid, you do not need IQ Source for this piece. If three or more land in silence, a conversation is worth it. A 60-minute call serves one purpose: diagnose which of the three layers is your actual bottleneck. Some teams have a working Layer 1 but no discipline. Others have discipline but the information is not in a place the agent can find. Others simply never wrote a decision down outside of Slack. Mapping that accurately is the prerequisite for anything else. If the call ends with “it is clear what we need to do,” you do it with your team, without us.
When it makes sense to install the system, AI Maestro is what we sell. That is not a weekend, and it is not a single call. We have been tuning the IQ Source brain every day for the last month, with two active clients changing the triggers week by week, and we are still tuning. The part we charge for is exactly that: the continuous-adjustment loop, the named owner of Layer 3, the rewrites of the routing CLAUDE.md every time a question reveals a gap, and the audit trail that survives a CTO or partner change. The difference between the team that starts on Tuesday alone and the team that has a reliable Team OS by end of quarter usually comes down to whether someone with outside discipline runs the third layer while the client’s team is busy putting out product fires.
The team whose reasoning can be queried in fifteen seconds pays one in 2027. The team that keeps answering questions from the memory of three people pays three and keeps believing the problem is hiring faster.
Frequently Asked Questions
Team OS is the three-layer architecture Aakash Gupta documented on May 8, 2026 with four real implementations. It runs on Claude Code as a Markdown repo where the team writes decisions, customer calls, and queries; anyone (or any agent) asks the repo in natural language and gets the answer in seconds without paging the human who happens to remember it.
The three Team OS layers are: shared context (the folder where everyone writes decisions, transcripts and queries with a CLAUDE.md as a routing table), shared queries (the pattern by which anyone, including an AI agent, asks the repo in natural language), and shared discipline (the rule that the feature does not ship until the repo is updated to reflect the decision).
According to Aakash Gupta's May 9, 2026 numbers, an average team loses 10 context questions per person per day at 10 minutes each, which equals 8 hours per person per week. In a 50-person company that adds up to 400 hours per week, the equivalent of one engineer-year burned every two months answering questions whose answers already exist somewhere in Slack.
AI Maestro installs the three Team OS layers in week one of an engagement: it defines the folder structure the team will feed, writes the routing CLAUDE.md, configures the triggers that keep the repo current, and leaves an audit trail that survives a CTO change. The question is not whether your team uses Claude. It is whether the decision your team made in February can be queried in May in fifteen seconds.
Related Articles
The harness is the moat: the model is now commodity
Cursor, Devin, and Replit run the same three frontier models. Swap the model and the products keep working. Swap the harness and they break.
Karpathy Described a Vault. We Built a Nervous System.
Karpathy's LLM Wiki hit 17M+ views describing memory. We have spent 18 days running the four layers around it: senses, nerves, immune system.