Context Engineering for Humans

Last year I built a product sourcing agent for my team at DGW. It connected to Slack. You could type a product request, and it would search across vendor catalogs and return options in seconds.

It worked. Nobody used it.

The promotional products industry is visual. People need to see the product, compare it, imagine it with a logo on it. A text-based Slack response wasn't meeting anyone where they actually work. I'd solved the problem the way I saw it, not the way my team experienced it.

So I rebuilt it. This time as a platform with a vendor directory, a decorator directory, a knowledge base, and sourcing all in one place. Multiple steps of value instead of one trick. The team started using it within a week.

The tool wasn't the problem. The context was.

That phrase keeps showing up in AI conversations. Tobi Lutke coined the term "context engineering" last year to describe the real skill behind working with AI: not writing better prompts, but providing all the context a model needs to do the job. Andrej Karpathy compared it to filling a computer's RAM with exactly the right information before the processor runs.

The entire AI industry is now organized around this idea. And the data says it's working for machines. Models are getting better because we're getting better at feeding them context.

But here's what I keep coming back to. BCG studied AI adoption across thousands of companies. Ten percent of the value came from the algorithms. Twenty percent from the technology infrastructure. Seventy percent from people and processes. Meanwhile, 95% of AI pilots stall before they deliver measurable impact.

The bottleneck isn't the model. It's us.

I see this at DGW every week. Someone on my team makes a vendor decision in a DM. The vendor gets downgraded, a margin changes, a client has a specific need. All of that context, the why behind the decision, lives in a conversation two people had. It never makes it into the system. With 20 people on the team, those scattered decisions add up to institutional knowledge the organization can't access.

That's not a technology problem. That's a context engineering problem for humans.

I started asking my team three questions when something breaks: What should the outcome look like? What went into it? Where is it actually breaking? Three parts. Not a process. A diagnostic. The same approach you'd take engineering a context window for an AI agent, except the agent is a person.

When I rebuilt the sourcing platform, I didn't start with the tool. I started with those questions. What's taking time? What tools are you already using? Where does it break? The answers told me what context my team actually needed. The tool was just the container.

The attention economy makes this harder. We can't beat it at the individual level. Notifications, Slack messages, dopamine loops. Every person on my team has a context window, just like an AI model. And it's already full before they sit down to solve a real problem.

But I think we can beat it at the institutional level. Build systems that reduce the number of small decisions so the big decisions get the focus they deserve. Move vendor decisions out of DMs and into shared channels where both humans and agents can see them. Make organizational knowledge a layer that shows up where people already work, not a destination nobody has time to visit.

A knowledge base is a snapshot in time. What I'm building is living context. When the team downgrades a vendor in the directory, the sourcing tool knows. When a margin changes in a shared channel, the agent adjusts. The decisions we're asking the agents to make are informed by the decisions the team is making.

I used to think I was building tools. I'm building context.

The same architecture works everywhere I look. At DGW, it's business context for employees. At Foster Greatness, it's community context for young people navigating systems that weren't designed for permanence. In an AI system, it's tokens in a context window. Curate the context, reduce the noise, and the thing, whether it's a model or a person or a community, does what it's good at.

Technology that reduces cognitive load frees people for relationships. That's the whole thesis. Not efficiency for its own sake. Capacity for connection.

We put so much time and effort and money into context engineering for machines. We almost never make that investment for humans. And humans are where 70% of the value lives.

P.S. If you manage a team and you've noticed the same pattern, the decisions that live in DMs and never make it into the system, I'd genuinely like to hear how you're solving it. Reply to this one.