The Context Future

LLMs have redefined how we produce software

In just six months, we've gone from writing software to describing software. We used to spend our time producing code. Now we spend our time producing instructions that produce code.

The future is clear. How we describe things is going to matter more than how we make them.

Every agent, its own dialect

LLM agent harnesses — Claude, Codex, Cursor, and others — have started to give us tools to provide context to agents: skills, commands, rules. Each harness names these things differently. Each harness stores them differently. Each harness reads them differently.

This is a new space. Good practice is unsettled and evolving. The kinds of standardisation and sharing that software long ago worked out for itself are currently absent for context.

We solved this problem before. Package managers solved it for code. Dependency files solved it for environments. We did not solve it for context, and context is what agents actually run on.

The result is fragmentation. A skill you write for one harness does not run in another. A rule you tune for one project does not travel to the next. Every team reinvents the same instructions, in a slightly different dialect, for every tool they adopt.

This is waste. It is also a missed opportunity, because context — unlike code — is largely reusable. The way you want an agent to write tests, structure commits, or reason about a domain rarely depends on which harness happens to be running it.

What good practice needs

Software needed a few things before it could scale past individual projects: a shared format, a way to publish and discover packages, and a way to sync them wherever they were needed. Context needs the same things.

• A shared format. One way to describe a skill, a command, a rule, readable by any harness, written once.
• A publishing layer. A way for teams and individuals to package context and share it, the way we share code.
• A sync layer. A way to keep that context consistent across every environment an agent might run in.

None of this exists yet as a standard. It exists as a dozen incompatible conventions, one per vendor.

The challenges

None of this is easy. Here is why.

There is no agreed vocabulary yet. What one harness calls a skill, another calls a rule, and a third calls a custom instruction. Before you can standardise anything, you have to agree on what the thing even is.

Vendors have limited incentive to make context portable. A walled garden keeps teams inside a single tool. An open standard makes switching easy, which is good for teams and bad for lock-in. Any standard that succeeds will succeed despite this, not because of it.

The space moves fast. Harnesses change their conventions every few months. A standard that cannot keep pace becomes another abandoned spec.

Sync requires trust. Context often includes credentials, server configuration, and internal instructions. Teams will not sync that across tools unless they trust the layer doing the syncing.

And adoption is a chicken-and-egg problem. A standard is only useful once enough harnesses and skill authors use it, but nobody adopts a standard that nobody is using yet. Someone has to go first.

The possibilities

If context becomes portable, day-to-day work changes.

Skills become something you write once and reuse, not something you rebuild inside every tool you touch. Teams keep the way they want an agent to test, commit, and reason about their domain, regardless of which harness they happen to be running this quarter.

Your conventions travel with you. Onboarding a new tool stops being a rewrite and starts being a redirect: point the new harness at the context you already have, and it behaves the way your other agents already do.

The opportunity if we succeed

If this works, context becomes infrastructure. Not a feature inside one tool, but the layer every tool runs on top of.

Infrastructure like this only gets built once. Package managers, browsers, and cloud platforms all passed through this same moment: young enough that nobody owned the standard yet, important enough that whoever set it ended up underneath everything built afterward. Context is at that moment now.

The timing is not incidental. Software is six months into describing itself instead of writing itself. Every team that builds with agents from here needs a context layer. That is not a narrow audience. That is the direction the entire industry is moving.

The position compounds too, though not through lock-in. A team's context in a shared layer becomes the record of real, ongoing tuning: how they want tests written, commits structured, an agent to reason about their domain. That record has weight. The layer holding it becomes something teams keep using because it already knows how they work, not because leaving is blocked.

Build the layer while the category is still unclaimed. That is the moment to be early to.

This is bigger than software

Software is where this problem shows up first. It is not where it stays.

Developers were the first to hand real work to agents, so developers are the first to feel the fragmentation. But the shape of the problem has nothing to do with code.

A support agent needs customer history and policy. A sales agent needs deal history and account context. An operations agent needs the process it is meant to run, and the judgment calls a person used to make by hand.

None of that is code. All of it is context. And it hits the same wall: built inside one vendor's memory, gone the moment the team switches tools.

Every process AI touches will eventually need a place for that context to live, in a form that outlasts whichever tool happens to be running it today. Code is just the first process that got there.

Automatic's mission

Automatic's mission is to fill this gap. Automatic aims to become the default context layer for AI, regardless of agent, environment, vendor, or process.

Automatic starts with code, because that is where the fragmentation is sharpest today. It is a workspace manager that syncs the context defining how your agents behave, skills, MCP servers, instructions, across Claude Code, Cursor, Copilot, and whatever comes next. Write your context once. Run it everywhere.

The same problem is coming for every process AI touches. The layer built to hold it does not stay confined to where it started.

The invitation

This space is young enough that the standard has not been set. That is an opportunity, not a problem. We are inviting the people building agent tooling — harness authors, skill authors, teams shipping their own internal conventions — to help set it.

tryautomatic.app