The Ecosystem

Everything published to Axon is installed the same way and named the same way.

axon install @axon/discord        # a module — your agent gains tools
axon install @cody/eslint-scout   # a prompt — your agent gains a task

The registry holds one kind of thing: an artifact with a scoped name, an owner, and versions. What varies is what's inside it.

The four kinds

Prompts — a unit of work. An instruction you can hand an agent, packaged so someone else can hand it to theirs. No build step, no dependencies, no runtime surface. The smallest publishable thing in Axon, and the easiest to author. See Prompt Packages.

Modules — a capability. Tools, routes, and boot-time setup that plug into the agent's lifecycle. Installing one is a single command; building one means working with the build step. See Modules.

Cognets — a brain. The cognitive loop itself: how the agent thinks, what it does between waking and stopping. Selected in config rather than installed, and swapping one changes how your agent reasons without changing a line of your code. See Cognets.

Benches — an experiment. A scenario run against many configurations of an agent, so a claim about which is better has evidence under it. Cloned rather than installed. See Benchmarks.

Names are global

A name like @cody/eslint-scout is unique across every kind — there is no separate module namespace and prompt namespace. Publishing under a scope requires that the scope is yours, which is the whole authorization story:

@axon/discord        # published by the axon org
@cody/eslint-scout   # published by cody

That is also why axon install needs no --kind flag. The name resolves to exactly one artifact, and the CLI already knows what it is.

Where to start

Most people arrive wanting to use something, not publish one. Installing is one command and is covered in Installing.

When you do want to publish, start with a prompt. It is text — there is nothing to compile and nothing to configure, so the whole lifecycle is one command. Modules and cognets are deeper, and they are deep on purpose: they reach into the runtime, and the docs for authoring them live with the rest of the internals.