Context Beats Prompts. Policy Beats Hype.
Every team lands on the same questions
I have run over ten workshops with developer teams, sales organizations, and mixed-role groups in the past year. Every time the same thing happens: when a team sits down with real problems from their own backlog and actually uses the tools, policy questions surface. Not because someone planned it. Because practice forces decisions.
Not identical questions. But the same decision domains. Every time.
One group builds a module directly in production code. Five dollars in model cost. No documentation. No change request. Who owns that code now?
Another group cannot get the external tool running. They download a local language model on a laptop and build natural language search in their route planning product. No external API. No help. They deliver. But what data went through the model?
A third group plans and executes 60% of what their development lead calls "at least two weeks of full-time work" in a single day. A senior developer predicted edge cases that the model independently identified in the next query. Same prompt as everyone else. The difference? The context in the window. Not the prompt.
Eleven policy questions surfaced during a single day. None of them planned.
This is not unique to that team. It is a pattern.
The questions that always surface
After ten workshops I have seen the same decision domains emerge regardless of industry, team size, or technical maturity. Here are three that come up in every session.
Ownership of AI-generated code
Who owns the output? The person who wrote the prompt? The person who committed the code? The organization?
The answer is simple: whoever commits the code is personally responsible. Regardless of whether it was AI-generated or handwritten. Most teams already have consensus on this. But they often lack a formal policy to lean on when a question is raised six months later.
Data boundaries
What may be sent to external models? Personal identifiers — never. Customer data — case by case. Internal code — usually permitted. Financial data and contracts — the gray zone.
The real risk is not someone deliberately breaking rules. It is someone sending information to a free tier without thinking about data retention. Without policy, every individual decides for themselves. That is not a strategy.
Knowledge sharing
How does the team share AI experiences internally?
Without a system, insights disappear with the individual. One CTO set up dedicated research sessions. First week, one person participated. The presentation was so good it triggered spontaneous participation. Culture first, structure second.
These are three from a set of eleven recurring decision domains. Each one surfaces differently depending on team size, technical maturity, and the kind of work being done. The complete framework — all eleven questions mapped against three responsibility levels — is what we work through in Track 3 and Track 4 workshops.
Policy lives where the work happens
A policy that lives in a document is not a policy. It must live where the work happens.
For teams using Claude Code or similar repo-aware tools, this means decisions go into a CLAUDE.md or CONVENTIONS.md at the repo root. Every session starts with the tool reading your guidelines. Policy is not something you need to remember. It is in the context window from the start.
The concept of building organizational logic directly into a shared repo — a "Company OS" — is worth exploring for any team doing serious AI-assisted work.
Seniority is the multiplier
This is what I see in every workshop: seniority is the multiplier. Not prompt technique.
The developer with 15 years of system experience beats the one who can write "better" prompts but does not understand the domain. Every time. The gap is widening.
The prompt is the least interesting variable in the equation. What determines output is what the tool already knows when you ask. The context window. What is loaded before you type a single line. That is the whole thing.
Policy amplifies this. It protects the organization from confident-sounding wrong answers shipping to production. It ensures that experience trumps speed. That the person who knows the most also gets the greatest leverage.
Conclusion
The industry spends disproportionate energy on prompts. It sells courses. It sells newsletters. But it builds nothing.
What builds something: real problems, real tools, real decisions. Policy that grows from practice. Not from an inspiration talk.
Every team I have worked with has landed on the same insight: it is not about formulating better questions. It is about loading the right context and taking responsibility for the result.
Context beats prompts. Every time.