aeon on the Wire: MCP and a Fleet of Forks

The first batch of articles framed aeon as a scheduler. A repo of Markdown skills that a cron tick hands to a coding agent, over and over, without a server in the picture. That framing is accurate but it’s incomplete.

The bigger picture is that a single aeon instance is a node. It sits on the wire, exposed to other agents through an open protocol, running alongside a fleet of forks that other operators own. Skills are not private to a fork - they can be invoked from outside, they can be composed across instances, and the forks-in-the-wild form a swarm with its own coordination primitives.

This article covers the two surfaces that make aeon a node instead of a script: the MCP server and the fleet skills.

The Model Context Protocol is how an aeon instance exposes its skills to an outside agent. Each skill in the catalog shows up as a callable tool that another agent session can use directly - no need to bundle the skills into your own product or copy the repo.

mcp-server/ is the component that does this. Wire it into a Claude Desktop or Claude Code session, and every aeon skill shows up as a callable tool in that session’s tool list. You DM Claude, “use the token-movers skill to check the last 24 hours,” and Claude picks the tool, calls it, waits for the response, and folds the output into its answer.

The consequence: if you build an agent-first product on top of aeon, the aeon instance is the tool provider and your agent is the consumer. Each side owns its own runtime. Your agent calls the skills from wherever it lives; the aeon instance runs them and returns the output.

For the aeon operator this means the same skill catalog serves three modes of use without any change:

• Scheduled runs, driven by cron on GitHub Actions.
• On-demand runs, driven by a human hitting a dashboard button or sending a Telegram message.
• Agent-driven runs, driven by another agent session using aeon as a tool provider over MCP.

Same skill file. Three consumers. No adapter layer between them. And because MCP is an open protocol with a public spec, any agent that speaks it is talking to aeon on the same terms - the skills stop being an aeon-only asset.

The second surface is the one most agent frameworks don’t have at all. aeon treats forks in the wild as a distributed swarm.

A cluster of fork-* and fleet-* skills gives an instance the ability to see, evaluate, and coordinate with other aeon forks. fork-fleet is a divergence monitor - it tracks where the fleet’s active forks have drifted from upstream in code (unique commits, new or modified skills) and in config (enable / var / model / schedule). fleet-control operates a set of managed instances from memory/instances.json: health-checks, cross-instance dispatch, status snapshots, and a scorecard mode that rolls up runs, tokens, cost, and reliability across the roster. spawn-instance clones the agent into a new GitHub repo, configures its skills, validates it, and registers it in the fleet.

The mental model: a single aeon instance is one node. The set of running forks - public ones, at least - is a network. The fleet skills let a node be aware of the network without pretending to own it. Each fork is still autonomous. Each operator still controls their own secrets, their own soul, their own strategy. What the fleet skills add is visibility and optional coordination.

The visibility side is straightforward. fleet-control’s scorecard looks at a set of forks - via public metadata, commit history, and the telemetry operators opt into - and reports which ones are healthy, which ones are stale, and which ones are running skills that are failing on other forks too. If a widely-used skill has started failing across the fleet, that’s a signal worth surfacing. If a specific fork has gone dark, that’s a signal too.

The coordination side is more novel. A skill on one node can trigger a workflow on another node via fleet-control, using GitHub’s existing dispatch API. This is not a distributed compute layer - it’s a way for one operator’s aeon to say “I need this thing done, and this other operator’s aeon is set up to do it.” Whether the receiving side answers is the receiving operator’s decision.

MCP is an open protocol with a reference implementation and a public spec. It is not aeon-specific. Any agent that speaks it can talk to aeon. Any framework that speaks it is talking to aeon on the same terms.

The alternative would have been to invent an aeon-specific protocol and call it a differentiator. That’s a common mistake in the agent space. It usually ends with a small ecosystem trapped behind a proprietary API and a big ecosystem going around it.

aeon’s bet is the opposite. Speak the protocol that already exists. Let anyone consume the skills. Let anyone contribute skills. Ship the framework, not the walled garden.

The side effect is that aeon skills stop being an aeon-only asset. A skill written for aeon works over MCP with any agent session that speaks the protocol. The catalog becomes portable in ways a proprietary system wouldn’t allow.

Once you accept that skills are portable, composition changes shape too.

Chains - the chains: block in aeon.yml - are the intra-fork composition primitive. Skill A runs, its output feeds skills B and C in parallel, their outputs feed skill D. All inside one repo, one workflow, one runner.

The inter-fork equivalent is coordination through the fleet. Fork X owns a skill that’s genuinely hard to write. Fork Y wants the capability. Y can pull the skill into its own catalog with install-skill and run it locally, or - when the skill needs X’s own secrets and runtime - ask X to run it via fleet-control’s cross-instance dispatch. Either way both operators keep their own secrets, their own soul, their own strategy.

This isn’t a hypothetical. It’s the shape the spawn-instance and install-skill skills already support. An operator spawns a specialized fork focused on one domain, keeps the roster in ECOSYSTEM.md, and either runs it themselves or lets other forks pull its skills.

Read together, MCP plus the fleet skills change what aeon is. Not “a repo you fork.” Not “a scheduler on Actions.” Both of those, and:

A node in an agent network. Exposed on the wire through an open protocol. Aware of other nodes running the same framework. Composable with agents that don’t run aeon at all, because the tool interface is a public spec.

The first article in the kickoff series argued that aeon runs while you sleep. This one argues that while it runs, it’s also reachable. Not as a service you subscribe to. As a peer, sitting on a protocol, waiting for a call.

The framework got a lot easier to plug into other systems in the last two months. The next batch of ecosystem work is going to lean on that.