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.

Eleven questions every team needs to answer

After ten workshops I have seen the same decision domains emerge regardless of industry, team size, or technical maturity. I call them "the eleven questions" - not because it is always exactly eleven, but because these categories cover what needs to be decided.

1. 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.

2. Commit discipline

Should commit messages be written manually or generated automatically?

AI-generated commit messages are often better phrased. But they remove a cognitive checkpoint. Writing the commit message by hand forces the developer to articulate what was done and why. That requires understanding. It is not overhead. It is the job.

3. Changelog as a thinking tool

Manual updates or automatic generation?

When a bug is reported months later, a structured changelog with version numbers is invaluable. The language model does not have your entire git history in its context window. But it has your changelog. Make it a checkpoint, not an afterthought.

4. Recording and transcription

When and how may conversations be recorded?

Laws vary by jurisdiction, but the relationship cost of secret recording is universal. Built-in meeting tools with visible indicators are generally accepted. External phone recording is harder. Agree on an approach. Policy reduces individual uncertainty.

5. 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.

6. Tool governance

Which tools are approved for work? Are free versions of ChatGPT permitted? What is the difference in security level between an Enterprise subscription and a free tier?

The question always surfaces when the team realizes half their colleagues are already using free versions for work. It is no longer a choice. It is a reality that needs managing.

7. Cost awareness

Visibility, not restriction. Show spend per developer. Regular check-ins. But not throttled.

One developer went from 50 dollars per month to 300 by switching to a more expensive model for a complex problem. Pedagogical question, not abuse. Expensive models for planning, cheap ones for implementation. Log files consume tokens as much as code files. Cost without value creation.

8. Knowledge sharing

How does the team share AI experiences internally?

Without a system, insights disappear with the individual. An internal channel where everyone shares one thing per week. Not a presentation. Not a report. Just: "I tried X, it worked / did not work." Raw data as the basis for a weekly summary.

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.

9. Terminology file

Internal abbreviations and concepts the language model does not understand.

Every organization has internal language. Product names, process steps, customer categories. When the language model processes internal data without this context, it misinterprets. A file with definitions, placed in the repo root or loaded into the context window, takes half a day to create and saves endless bad output.

10. Parallel context windows

Is it permitted to run multiple AI threads in parallel on the same codebase?

An update in one thread is not reflected in the other. Files changed in thread A are not updated in thread B. Conflicts arise. Recommendation: one thread per production task. Parallel threads for separate, independent tasks.

11. External data integration

What may be connected to AI tools? CRM data? Email? Customer systems?

Protocols like MCP servers make it possible to pull data from external systems directly into the context window. Questions: the policy for reading CRM data via AI, the policy for reading email via AI, GDPR aspects of EU servers versus US-based ones.

Three responsibility levels - a thinking tool

Not all policy questions need the same answer at every level. Think in three tiers:

Solo - individual experimentation. Guidelines to lean on, not micromanagement. This is where you test, make mistakes, learn. Rules are minimal but conscious.

Assignment - client or project delivery. Every line must be understood by the person delivering. Documentation is not optional. The person delivering must be able to explain why.

Company-level - code and processes representing the organization. Named commit ownership, shared policy, documented guidelines. This is where discipline is highest because consequences are greatest.

The eleven questions should be answered with these levels in mind. Code ownership applies at all levels. Parallel threads are most relevant at company level. Knowledge sharing is most critical at assignment level. The matrix is not static. It is a way to calibrate consciously instead of landing on default.

From decisions to daily practice

Thanks to Dan Rosenthal (workflows.io) for the "Company OS" concept that structures how a team can build organizational logic in a shared repo. We took that concept and adapted it based on what we see in workshops.

A policy that lives in a document is not a policy. It must live where the work happens.

Option A: Repo-native

For teams using Claude Code, Kilo Code, or similar tools.

Policy decisions go in a CLAUDE.md or CONVENTIONS.md in 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.

A terminology file with internal concepts. A context file with product descriptions. The work loop connects policy to every step:

• Read the project - the policy file is there
• Write a change request - the documentation requirement applies
• Choose a model - governance applies here
• Review every line - ownership applies here
• Commit - the commit message policy applies here

Option B: Repo-adjacent

For teams with shared codebases but without AI coding tools that read the repo.

A docs/ folder with policy files, linked from the README. Not as integrated as Option A, but better than nothing. Downside: the policy must be actively sought instead of being pre-loaded.

Option C: Tool-based

For mixed teams or organizations without a shared code repo.

Confluence, Notion, Teams wiki. Least effective. The policy lives far from where work actually happens. But realistic for teams where half the members never open a repo.

The feedback loop

Without it, policy dies. Rules accumulate but problems go unreported. No one knows if the guidelines are actually followed or if they are outdated.

One CTO published guidelines two months ago. No complaints. No approvals. Silence. That is not consensus. That is absence of feedback. Build a loop: a channel where the team reports what works and what does not. Without it, policy is decorative.

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.