Context as a First-Class Primitive: Why Your Agent's Capabilities Shouldn't Be Baked In

Currently, for most agents, the answer is “inside.” The tools it can call, the domain knowledge it relies on, the integrations it speaks to: all of it welded into the agent at build time. That works for a demo. It ages badly in production. Every new capability means touching the core, every fix means a redeploy, and the agent slowly calcifies into something only its original authors can safely change.

The more durable move is to treat context as a first-class primitive: something you can name, pass around, compose, version, and load on demand, rather than something embedded in the agent itself. Skills and connectors are the natural unit for that shift, but only if they’re treated as distinct, swappable entities rather than wired into the agent as static parts.

What “first-class” actually means

The phrase is borrowed deliberately. In programming languages, making functions “first-class citizens” (values you could store, pass, and compose) wasn’t a cosmetic change. It unlocked entire paradigms, because behavior became something you could manipulate rather than something hardcoded into control flow.

The same move applies to context. When context is first-class, capability stops being a property of the agent and becomes a thing in its own right: discoverable, swappable, ownable. And it helps to be precise about what “context” covers here, because it’s three distinct things:

• Knowledge: procedures, domain expertise, house style, the way your business actually does something. This is what a skill packages.
• Tools and actions: the ability to reach an external system and do something in it. This is what a connector provides.
• State: what’s actually relevant to the task in front of the agent right now.

Hardcoding fuses all three into the agent. Making them first-class pulls them apart into entities you can reason about independently. That separation is where the benefits come from.

One clarification, since “entity” is easy to read as “separate file.” It isn’t. A SKILL.md in a repo or a procedure in a Notion page is just packaging: necessary, but not the point. What makes something an entity is a runtime property: the agent can discover it, permission it, and load it on demand without its own code changing. git clone the skills repo into your build, or copy-paste that Notion doc into a system prompt, and the file boundary survives but the separation doesn’t. You’ve folded the capability right back into the agent. That’s still hardcoding, just with extra steps. The discovery-and-loading layer is what makes a file first-class, not where the file lives.

What it enables

Composability. When skills and connectors are distinct entities, you assemble capability per task instead of rebuilding the agent for each one. A support agent and a finance agent might share a CRM connector but load entirely different skill sets. You compose rather than fork, the same idea as skills composed over MCP tools. The combinatorial reuse is the whole point: n skills and m connectors give you far more than n + m worth of behavior.

A leaner context window. An agent that has every tool and every procedure baked in carries all of it on every request, whether or not the task needs it. That’s not just wasteful: it actively degrades performance, because the model’s attention is spread across two hundred tools it will never call, a decline Anthropic describes as context rot. When capability is loaded on demand, the agent pulls in only what the task requires: the shift from context bloat to context load. The context window stays relevant, and accuracy improves as a direct result.

Independent iteration. This is the one product owners feel most. If a connector’s API changes or a procedure needs updating, you fix the skill or connector, not the agent. The lifecycles are decoupled. No retraining, no redeploy of the core, no regression risk across unrelated capabilities. The team that owns the billing logic can ship a better billing skill without ever opening the agent’s codebase.

Reusability across agents. A well-written skill isn’t tied to one assistant. The same packaged knowledge can serve every agent in the organization, and one connector can back many workflows. Write the “how we handle refunds” skill once; every customer-facing agent inherits it. This is exactly the premise behind platforms like skilder.ai, which frames the goal as turning business knowledge into AI-ready skills you build once and deploy across every AI tool you use. The unit of work becomes the skill, not the integration-rewrite.

Runtime discoverability. Because capabilities are named entities rather than hidden branches in code, an agent can search for the right one when a task appears, instead of needing to know everything in advance. This scales in a way hardcoding never can: you don’t enumerate every capability at design time, you let the agent find what fits at run time.

Governance at the boundary. When a connector is a distinct entity, permissions, sandboxing, and audit logging attach to it directly. You can say “this agent may use the read-only analytics connector but not the one that issues refunds” as a configuration fact, not a code review. Security lives at a clean boundary instead of being scattered through monolithic logic, which also makes it auditable.

Ecosystem effects. Once skills and connectors are first-class, third parties can author them. Your core team stops being the bottleneck for every integration. Capability scales with the ecosystem rather than with your headcount: the same dynamic that turned package registries into the backbone of modern software development.

Testability. Each skill and connector is verifiable in isolation. You can test “does the refund skill produce correct guidance” without standing up the entire agent, which makes the whole system more maintainable as it grows.

The honest tradeoffs

This isn’t free. Pulling capability out of the agent introduces orchestration complexity: something has to decide what to load and when. Discovery quality becomes a real concern, which is why retrieval is becoming the new intelligence: if the agent can’t reliably find the right skill, a large library hurts more than it helps. Versioning and compatibility drift between an agent and its connectors need active management. Dynamic loading adds latency. And pulling capability in at runtime widens the surface you have to secure.

It’s worth being clear about which way the costs actually run, though. Orchestrating context, loading only the skills and connectors a task needs, reliably reduces an agent’s token consumption rather than adding to it: the model isn’t carrying hundreds of irrelevant tool definitions and procedures on every call. That trims the runtime overhead of orchestration itself, since there’s less to reason over each turn. The complexity moves into the loading and discovery layer, but the per-request footprint gets smaller, not larger.

None of these are reasons to bake capability back into the core. They’re reasons to invest in the orchestration, discovery, and governance layers: the parts that make a first-class system actually work.

The direction of travel

The bet underneath all of this is straightforward: the agent itself should be a relatively thin reasoner sitting over a rich, swappable substrate of context, the layer some now call a context lake. The intelligence isn’t in how much you’ve hardcoded. It’s in how well the agent can reach for the right knowledge and the right action at the right moment.

Skills and connectors as distinct, first-class entities are what make that substrate possible. Treat context as a primitive, and your agent stops being a monolith you maintain and starts being a system you grow.