How to Structure Agent Context for Team-Conforming Output
Agent output is often technically correct but not team-conforming. The fix is better context, not a better model. This guide specifies the required context.
No specialized background assumed. The focus is on engineering practice, not model internals.
This is:
Not a tutorial on how to use Claude Code. Not a prompt engineering cheat sheet. Not about replacing engineers.
Engineers remain responsible for output quality. Agents are instruments that require correct configuration to produce correct output.
Agents have no persistent memory of your team between sessions. Every session starts from zero. Without explicit context, the agent infers conventions from training data which reflects industry averages, not team-specific practices.
The context agents need is the same context a new team member needs: toolchain, structure, style, complexity, conventions, definition of done, and domain knowledge.
Most teams have never written that context down. Writing it down improves both agent output and team clarity.
- Agent output is correct but does not match team conventions
- Engineers spend time reformatting, renaming, restructuring
- The same corrections happen every session
- Different engineers get different agent behavior
- No one knows what context the agent has about the team
Without explicit context, agents infer conventions from training data. Training data reflects industry averages. Your team's specific practices are not in there.
- Review friction: PRs require style corrections unrelated to correctness
- Trust erosion: engineers stop relying on agent output
- Inconsistency: agent-generated code looks different from team-generated code
- Missed leverage: the agent could do more with better context
In this guide, priors are the structured, agent-readable form of that context.
An agent without team context will not produce team-conforming output. This is not a model failure. It is a configuration failure. The fix is engineering, not prompting.
- Toolchain: what tools, what versions, what commands
- Structure: where code lives, how it is organized
- Style: naming, formatting, complexity, docstrings
- Conventions: what the team actually does vs what the docs say
- Definition of done: what a passing review looks like
- Domain knowledge: what correct means in this problem space
All of these can be made explicit; doing so is the work.
Writing context for an agent forces a team to articulate what it actually does.
Observed outcomes:
- Agent output improves immediately
- Team conventions turn out to be less consistent than anyone thought (which is itself useful)
The priors written for an agent are often the clearest documentation a team has ever produced about how it works.
Three layers of context are required. Each answers a different question.
The Adaptive Conformance Specification defines foundational agent behavior: observe before acting, infer from evidence, conform to local patterns, stop rather than guess.
This is not team-specific. It applies to any agent working in any unfamiliar codebase.
→ adaptive-conformance-specification
The Adaptive Tool Discovery skill maps the capability surface of external tools: MCP servers, APIs, CLIs, SDKs.
An agent that does not know what a tool actually does will invoke it incorrectly or not at all. ATD runs discovery once and produces a persistent registry any session can load.
The Adaptive Onboarding skill captures team conventions in a structured, agent-readable format: toolchain, structure, style, complexity, docstrings, ownership, definition of done, and the norms that are never written down anywhere.
This is the layer most teams are missing entirely.
For domain-specific work, e.g., sensor data, financial models, medical devices, scientific instrumentation, agents also need to know what correct behavior looks like in the problem domain.
Expected ranges, known failure modes, anomaly definitions,
calibration norms: context is captured in ao-domain.toml
alongside team conventions.
This functions as a fourth layer when domain correctness
cannot be inferred from code or tools alone.
Read ACS for foundational behavior
Read ATD registry for tool capabilities
Read AO context for team conventions
Read domain context for problem domain
Then begin work on <task>
Each layer narrows agent output to what is correct for this team, these tools, this problem.
A prompt template tells an agent what to say. A skill specification tells an agent how to reason and what evidence to require before acting.
A prompt template produces consistent phrasing. A skill specification produces consistent reasoning.
Skill specifications constrain reasoning, enabling consistent behavior across novel situations.
A prior is only useful if the agent can verify it, apply it, or flag when it is violated.
Good prior entry:
max_function_lines = 30 # verified against observed code patternsWeak prior entry:
code_quality = "high" # agent cannot act on thisRules for writing effective priors:
- Be specific enough that a violation is detectable
- Distinguish confirmed facts from inferred patterns
- Record where the convention came from
- Note when team practice diverges from best practice and what stance the team takes on the divergence
Entries in context files (for example ao-config.toml)
carry a confirmed flag.
confirmed = true -> agent accepts without re-inferring.
Use for stable toolchain facts.
confirmed = false -> agent verifies against observed patterns.
Use for style and complexity conventions that may vary by repo.
When team conventions diverge from community best practices, the agent must know what to do.
best_practices_stance = "balanced"
# prefer_team # follow team; flag divergences
# balanced # follow team; flag significant divergences for human review
# prefer_standard # follow best practices; flag team differencesThis is a team decision, not an agent decision. Making it explicit prevents silent conformance or silent override.
After loading priors and running a task, ask:
- Does the output match naming conventions?
- Does the output match structure conventions?
- Are functions the right size and complexity?
- Do docstrings follow the team style?
- Would this pass code review without style corrections?
- Does the output require human interpretation to resolve ambiguity?
If the answer to any of these is no, the problem is in the priors. Update them and re-run.
The ACS, ATD, and AO skills in the adaptive-interfaces org are starting points, not mandates.
Fork when:
- The team has stopping conditions ACS does not define
- The tool surface requires ATD extensions
- Team conventions require AO schema additions
- The domain requires a domain context file
Keep the core structure: the six-step workflow, the evidence-first principle, the explicit gap recording. These are the discipline, not the detail.
A simulated engineering team works with temperature/frequency sensor data. They use PTAT circuits and proprietary processing pipelines. They need agents that can:
- Write tests that match team conventions
- Detect anomalies in sensor batch data
- Report findings in a structured, auditable format
The sensor simulator provides:
- A synthetic PTAT data generator with injected anomalies
- Processing functions for agent test generation
- Pre-generated batch data for scenario runs
How the team writes Python: uv, src layout, hatchling, ruff, pyright strict, Google docstrings, pytest, max 30 lines per function.
What the sensor data tool does: inputs, outputs, failure modes, rate limits, constraints.
What correct means for PTAT sensor data: expected frequency-temperature relationship, operating ranges, anomaly definitions, calibration check intervals.
Read ACS
then read ATD registry
then read ao-config.toml and ao-config-python.toml
then read ao-domain.toml
then execute the task using the loaded priors and evaluation scenarios
- Test naming matches team conventions
- Fixtures used correctly
- Assertions match domain expectations
- Anomaly at sample 400 correctly identified
- Report structured per team standards
- Two conventions were inconsistent across repos
- The ATD registry revealed an undocumented failure mode in the sensor API
- The domain context forced a conversation about what "drift" means. The team had two definitions.
All three surfaced before the agent wrote a single line of test code.
The framework, including ACS, ATD, AO, and domain context, applies to many domains, for example:
- Medical device validation
- Financial model testing
- Infrastructure automation
- Scientific data pipelines
- Any team where code review matters
The sensor testing example is a vehicle. The discipline is the destination.
Writing effective priors produces:
- Clearer onboarding documentation for new engineers
- More consistent code review feedback
- Explicit conversations about conventions that were previously implicit and inconsistent
- Documentation that reflects what the team actually does
The agent is the forcing function. The benefit extends beyond the agent.
Writing a skill specification is an engineering task:
- It requires precision
- It requires testing (the evaluation scenarios)
- It requires maintenance (refresh when conventions change)
- It produces artifacts that can be reviewed, versioned, and forked
Teams that treat skill writing as engineering produce agents that are reliable, auditable, and improvable.
Teams that treat it as prompt hacking produce agents that work sometimes and fail in ways no one can diagnose.
Team effectiveness with AI agents is proportional to how precisely the team has articulated how it works.
Writing that down is not overhead. It is the work.
Understand the foundational behavior protocol. This is the foundation all adaptive-interfaces skills build on.
Generate ao-context.toml for the most representative repo.
Review what the agent inferred.
Fill gaps by hand.
Have the conversation the priors surface.
Start a session with ACS and AO loaded. Give the agent a real task. Evaluate the output against team conventions.
Update priors where output missed. Re-run. Improvement should be immediate and traceable.
Add ATD for the tools. Add domain context for the problem space. Fork and tune the skills for specific team needs.
adaptive-interfaces/
adaptive-guide ← start here
adaptive-conformance-specification ← foundational behavior (ACS)
adaptive-tool-discovery ← map your tools (ATD)
adaptive-onboarding ← capture your team (AO)
adaptive-sensor-testing ← complete worked example
adaptive-skill-lab ← build and test your own skills
MIT © 2026 Adaptive Interfaces