Knowledge triggered by a decision

Somewhere over Nevada, on the plane home from Demo Day, the three tools I'd shown the DGW team collapsed into one thing in my head. A knowledge base. A vendor directory. A product search agent. Three separate projects. They weren't three. They were one system where knowledge gets taken in, stored, and surfaced when it's needed.

That's the visible part. The structural part is why a nine-person team can run a system like that at all, and couldn't have two years ago.

Two things changed underneath us.

Coordination got cheap

Clay Shirky's argument from 2008: institutions exist because coordination is expensive. When the cost of coordinating outside an institution drops below the cost of coordinating inside one, the institution loses its structural advantage.

The new variable is AI, and the formal version has a paper behind it. Klein and Wieczorek's "The Headless Firm" shows that in protocol-mediated agentic systems, integration cost drops from O(n²) to O(n). In plain language: every new component used to negotiate with every other component it touched. Now it just conforms to a shared protocol.

A lot of that overhead was never load-bearing in the first place. Harang Ju at Johns Hopkins classified 65 enterprise workflows and found 74% are monotonic, meaning information flows one direction and finishing a stage never requires going back. His estimate: 24 to 57 percent of what organizations spend on coordination isn't necessary for correctness.

I see this at DGW. When someone's out, it becomes all hands on deck. Sounds like teamwork. It's a coordination miss. Everyone steps off their own work because knowledge about that person's accounts and vendor preferences lives only in their head. Status meetings, check-ins, Slack response windows. All of that exists because there's no trusted system to answer "where do things stand?"

Meetings should be about growth, culture, the work that genuinely needs people in a room thinking together. Account status and vendor checks are monotonic. The system should handle them.

A convention for sharing knowledge

The other half is that a format for sharing procedural knowledge got standardized.

In December 2025, SKILL.md shipped as an open standard. Instead of building a custom agent for every task, you write down the procedural knowledge, the decision frameworks, the reference materials, and any capable agent picks it up. The metaphor from the team that built it: a skill is an onboarding guide for a new hire.

That's the metaphor that hit me. At DGW, onboarding is shadowing. The new person only sees processes that happen to come up while they're watching. Edge cases, vendor preferences, and client expectations stay invisible until you hit them. The biggest source of knowledge for a new employee isn't knowing everything. It's knowing where to ask the right question and get the right answer.

That's the same design problem SKILL.md solves for machines. Progressive disclosure: don't load everything up front. The agent discovers skills at startup, activates full instructions when a task matches, and loads supporting files only when the work requires them.

OpenAI's Codex Skills independently converged on the same pattern. Over 30 agent products have adopted it, from Claude Code to GitHub Copilot to Cursor to VS Code. When competitors arrive at the same format without coordinating, that's a standard validated by market behavior, not an announcement.

The same pattern, everywhere

I didn't learn progressive disclosure from a paper. I learned it trying to absorb medical information about my daughter's diagnosis while managing the stress that comes with that kind of change. You can only intake so much at once. If someone had handed me everything I'd eventually need to know on day one, it would have been paralyzing.

Not the same weight. Same shape.

Running, for instance. Zone 2 base first. Then threshold and strength. Then nutrition past 10 miles. Then race strategy. Try to learn it all up front and you get overwhelmed. It's much easier when you only get the information you need at the point you need it.

Vendor sourcing, medical care, endurance training, work onboarding. Everything has this need for specific information at a specific point in the journey. Being intentional about the user design of knowledge is the next step.

That's where machines can genuinely help. Not as tools we use or threats we manage. As a relationship. They've got the capacity to aggregate knowledge, store it, and handle the progressive disclosure so the right information reaches us at the right moment. We've got too much going on to do that for ourselves.

When people feel burnt out, a lot of it is because they're trying to manage everything at once. Organize what you know so you're only thinking about one thing at a time and you get capacity back. Capacity to breathe, to be present for the people around you.

What that looks like at DGW

Someone on the team referenced a vendor decision in a public Slack channel last week and immediately said it should be updated in the knowledge base. Nobody told them to. There was no policy. The system had already become part of how the team thinks about sharing information.

The principle underneath: knowledge triggered by a decision, not stored in a location.

A note that a vendor is overloaded and missing delivery dates isn't relevant to everyone all the time. It needs to surface when someone is making a decision about decoration method and vendor for that specific use case. It can't sit in a separate system the person isn't going to check every time.

A year ago I would have thought of a knowledge base as a Notion page with a bunch of Markdown files. Storage. Now we're building a system where vendor information and order history inform a sourcing agent, where HubSpot and our order processing system trigger client communication off events instead of someone remembering to follow up. On Foster Greatness, we're building a resource tool that works in every zip code. A year ago we had to link out to third-party tools and break the brand and the experience. Now a small team can own that capability end to end.

The institutional form is changing

This isn't a productivity story. It's an institutional form story.

A nine-person team can now do what a forty-person team used to do. Not because anyone got more efficient. Because the coordination floor collapsed and a shared convention emerged for how knowledge travels. Either alone is interesting. Together they change what kind of organization you need to be.

Microsoft's 2026 Work Trend Index found a consistent 7 to 12 point gap between what they call Frontier Professionals and everyone else. The differentiator isn't tool selection or AI sophistication. It's whether workflows are documented, repeatable, and shared. Even at the frontier, adoption tops out below 30%. The window is wide open. The race is not over.

We can grow this business 5 to 10x without adding employees. That reduces onboarding strain. It reduces burnout. The freed capacity doesn't just go to revenue. I've done more on the mission side in the last three months than I have in years. The system gives people more time with their families, more time with the things they're passionate about. That makes them better at the work and more connected to it. The loop is circular.

The same technology can produce broad-based gains or concentrate them at the top. The convention layer doesn't decide. We do.

P.S. If your team is small and you're starting to feel the floor shift, reply and tell me what changed. I'm collecting these stories because I think the pattern is bigger than any one company.

The three papers behind this issue, if you want to go deeper: Klein and Wieczorek's "The Headless Firm", Ju's "When Coordination Is Avoidable", and the Agent Skills open standard.