the names we
give our agents

Every tool in the new wave of AI-assisted development has arrived, independently, at the same need. And each one has given it a different name.

Cursor wants a .cursorrules file. Claude Code reads from CLAUDE.md. Kiro uses STEERING.md and organizes its agent context into “powers.” Others expect AGENTS.md, or offer folders labeled “skills” and “memory.” Some have begun building meta-artifacts — skill builders, power builders — tools whose purpose is to help the agent construct other context artifacts. Tools for making tools for managing what the agent knows.

And the surface area extends beyond files. Tools now offer rule systems, workflow definitions, hooks that trigger before or after specific actions. Each adds its own mechanism, its own vocabulary, its own assumptions about when and how context should load.

The names are different. What's inside them is remarkably similar. A shared description of a person and the environment they work within: their goals, their team's conventions, their tools' constraints, their accumulated judgment about how work should go.

The names are doing real work, but they are not converging. That suggests that the underlying concept hasn't been found yet. The vocabulary thrashes because the abstraction is still missing.

Look at the metaphors embedded in these naming choices.

“Steering” borrows from vehicle control. The agent is something you direct. The file is hands on the wheel.

“Memory” borrows from cognition. The agent is something that knows you, a colleague who recalls your preferences without being told again.

“Rules” borrows from governance. The agent is a system to be constrained.

“Skills” and “powers” borrow from game design. The agent is something that grows, that accumulates capacities. The file is an unlockable.

Each metaphor carries a different assumption about where control lives. These are design philosophy disagreements, but nobody is having them explicitly. They are being resolved through naming conventions, one product at a time.

And yet when you open these variously-named files, the substance converges. Which means the disagreement is not about what these artifacts do. It is about how the interaction between person and agent should work.

Decompose what actually lives inside these artifacts and most contain five concerns:

Identity — who I am, what my role is, what matters to me.

Preferences and approach — what I favor, how I decompose problems, what I notice in code review. The layer that distinguishes a senior developer's context from a junior's.

Domain knowledge — what this project is about, what the codebase does, what conventions we follow.

Constraints — when to do X, never do Y, always check Z before proceeding.

Workflow — how work should flow. Write tests first, use feature branches, run linting before committing. Procedural instructions that describe process, not boundaries.

These concerns change at different rates, are governed by different people, and serve different purposes. But in every tool today, they collapse into a handful of artifacts: a markdown file, a settings panel, a rules folder. Nobody decided that a person's reasoning heuristics and a codebase's architecture should live side by side. Each tool needed some way to encode how the agent should behave, and the simplest implementation won.

That simplicity reveals a deeper assumption. Every tool today is designed around one axis: one person configuring one agent. The design vocabulary is machine-centered: how to feed context to a model, how to format instructions for inference.

But the trajectory is away from one person and one agent. Agents are gaining autonomy, operating across larger scopes with less human oversight. In that world, organizational intent — compliance policies, security guardrails, architectural standards — needs to flow into agent behavior directly, not through a single developer editing a markdown file. The question is not how one person steers one tool. It is how an organization's vision, constraints, and promises reach the systems that act on its behalf.

Even the tool builders have not reached this question yet. OpenAI's guidance for engineering teams puts documentation guidelines, coding conventions, and release workflow instructions into a single AGENTS.md, with no discussion of who authors it or how disagreements are resolved. Anthropic's skill creator is thoughtful about writing good agent instructions, but has no concept of scope. One person builds the skill. The question of what happens when behavior affects an entire team is not in the design.

The promise of an agent is agency. A well-configured agent amplifies what you can do: the context you build is the augmentation. Some tools dynamically activate context based on what you're working on. Others accumulate understanding of how you think over time. The longer you use them, the better they become at helping you.

But consider what is actually accumulating. When Gmail retained your email history or Spotify your playlists, what built up was data — records of things you did, exportable in principle. What builds up in an agent is closer to a working relationship. Not what you did, but how you decide. How you decompose problems. When you want the tool to proceed and when you want it to stop and ask.

Much of this is explicit — configuration files, mostly markdown, technically portable. But the relationship is not in the file. It is in how the file meets the orchestration: which tools the agent invokes, how it searches your codebase, how it chains operations together. You cannot see how much your configuration is actually shaping behavior. You cannot tell which of your instructions the agent is weighting, which it is ignoring, which are interacting with the orchestration in ways you did not intend. The context is opaque even to the person who wrote it.

Orchestration should be a differentiator — that is how tools compete, and the competition produces real value. The problem is that context and orchestration entangle. Preferences, team conventions, and domain knowledge get woven into a layer that cannot be inspected, and the resulting behavior becomes something neither the file nor the harness fully explains. What is lost when switching tools is not data. It is a working relationship that can neither be seen clearly nor taken elsewhere.

This entanglement obscures a structural reality. Not all context has the same owner. Some is personal: my writing preferences, my communication style, my working patterns. Some is shared: a team's naming conventions, the architectural principles governing a codebase. Some is organizational: compliance guardrails, security policies, centrally governed. And some is situational: this codebase, this sprint, this product.

Nothing in the current landscape handles these scopes. There is no way to share a piece of agent behavior with a team, have it debated collectively, keep it in sync, while also maintaining a personal layer that remains yours. There is no inheritance model, no override logic, no visibility into how these layers compose.

When these files live in a code repository, they get some governance incidentally: pull requests, version history. But version control solves for authorship, not authority. It tells you who changed a file. It does not tell you who should be able to change which parts of agent behavior. And much of this context does not live in repositories at all. It lives in product settings, in chat memory, in configurations that only one person can see.

This matters because agent context differs from every previous shared-convention artifact — style guides, runbooks, onboarding docs — in one crucial way: it is executable. Those earlier artifacts had a human between the document and the behavior, someone who interpreted, applied judgment, caught contradictions. Agent context has no interpretation step. The instructions become the behavior directly. A stale style guide is merely annoying. A stale steering file produces wrong behavior at machine speed.

The scoping problem would be hard enough if these artifacts were static documents. But the gap is widening.

Modern agents are not static systems. They pull files, search codebases, call APIs, retrieve documentation, all mid-conversation. The domain knowledge layer is already fluid. An agent can find what it needs in your codebase as it works.

What remains static is the steering layer: the preferences, the conventions, the behavioral rules. These are loaded at session start, if they are loaded at all, and held for the duration. You cannot, mid-task, reach for “my team's conventions for naming Asana tickets” unless that was already in the context when the session began. You cannot invoke a specific set of architectural principles from a related project because the moment calls for it.

Kiro's powers are interesting precisely because they begin to bridge this gap. The tool context and the steering context activate together, dynamically, based on what you're working on. That bundling — capability and behavior arriving as a unit — is a meaningful design move. Research on Recursive Language Models pushes further, proposing agents that programmatically manage their own context, fetching and processing pieces as needed rather than holding everything in a fixed window.

People can steer agents manually: @-mentioning files, correcting behavior mid-conversation, choosing which tools to invoke. But manual steering requires presence, and the trend is toward autonomous execution where the agent runs with minimal oversight. In that setting, the steering file is the only context the person provides. Whatever it does not cover does not exist. The gap between what you can steer and what you actually steer widens as autonomy increases.

So where might the answer live?

If you reason from the concerns themselves (identity, preferences, domain knowledge, constraints, workflow, changing at different rates, governed by different people, scoped to different contexts) the shape starts to suggest itself.

You would want a portable identity layer. A person's preferences, style, working patterns, structured so that any tool that speaks the format can read them. This is the layer that follows the person, not the product.

You would want a shared context protocol, not just for tool connectivity, which MCP addresses, but for the steering layer. Something a team can collaboratively author, version, and govern, with changes visible and reviewable. Something closer to how teams manage infrastructure configuration than to how they currently manage markdown files in a repo.

You would want scoping and composition rules. When personal preferences meet team conventions meet organizational guardrails, the resolution should be legible, not buried in whichever file the agent happened to read last.

And you would want both automatic and deliberate context loading. Systems that activate relevant context based on what you're working on, but also the ability for a person to reach for specific context when the work calls for it.

None of this is technically exotic. The problem of layered, scoped configuration with conflict resolution has been solved before, and the solutions are instructive.

Consider CSS. A browser rendering a page might encounter a font-size declaration from the browser defaults, the site's global stylesheet, a component-level rule, and an inline style — all claiming authority over the same element. CSS resolves this through cascading specificity: each layer has a defined priority, more specific selectors override more general ones, and the resolution is deterministic. You can inspect any element and see exactly which rule won and why. The system is legible. Conflicts are not hidden; they are surfaced and resolved by explicit rules.

Now map that onto agent context. A developer working on a payment feature might have personal preferences (explain reasoning before showing code, prefer functional patterns), team conventions (log all API errors with full request payloads for debugging), organizational guardrails (never log PII or payment card data), and situational context (this codebase uses TypeScript strict mode). When a payment API call fails, the team convention and the organizational guardrail directly contradict each other. Today, the resolution is opaque: whichever instruction the model weights most heavily, or whichever appeared last in the prompt. There is no inspector. There is no specificity rule. There is no way to know which layer won.

Infrastructure configuration tells a similar story. Terraform, Kubernetes, and their peers manage layered defaults through explicit override hierarchies — base configurations that can be selectively overridden by environment-specific values, which can in turn be overridden by deployment-specific settings. The layers compose predictably. Changes are diffable, reviewable, and reversible. Access control systems add another dimension: scoping rules that determine not just what applies, but who is allowed to change what at each level.

The agent context problem is not a new kind of problem. It is a known kind of problem appearing at a new layer. The question is whether we recognize it in time to apply what we already know, or whether we rediscover these patterns the hard way, through failures that accumulate when executable configuration lacks explicit conflict resolution, and through fragmentation, as solutions emerge piecemeal at the code review level, the spec level, the platform level, each solving a slice of the problem without coordinating with the others.

The naming will settle eventually. Some term will win and the abstraction will harden.

When it does, what matters is whether the hardening happens around products or around people. Whether the systems that govern agent behavior are legible to the organizations that depend on them, or opaque, proprietary, and controlled by whichever vendor happened to ship first.

The encouraging signs are real: convergence around open protocols, dynamic context systems, persistence layers, community-driven format proposals. The open-source movement toward personal, self-hosted AI makes a different architecture genuinely possible.

The names we give our agents tell us what we think the relationship is. But the more interesting question is what we put inside them, who gets to shape it, and whether the boundary between what belongs to a person, a team, an organization, and a platform remains something we can see. That boundary is still being drawn. The window in which these defaults can still be shaped is the window we are in.