Agents

An Agent is a role you define. Like a capable assistant, it's fully described by who it is, how it thinks, and what it's equipped with — three decisions, each a focused section of the agent editor. You chat with a published Agent directly, or put it on standing duty with a Workflow.

Persona

Who the Agent is and how it works: the natural-language description of its role, judgment, and working style — "Pragmatic senior engineer. Reads before it writes." The persona is the durable part of the role; it travels with every version the Agent publishes.

Model

How the Agent thinks. You pick a preset — powerful, balanced, or quick — resolved against the workspace's provider and model allowlist, so an Agent can never reference a model the workspace hasn't sanctioned. A preset carries a reasoning effort as well as a model; the Agent inherits it and can override it. See Models.

Context

What the Agent is equipped with: MCP connections (workspace or personal) and authored skills, drawn from the workspace's Context library. Equipment is packaged straight into the compiled agent, so a published Agent carries its tools and knowledge with it. See Skills for how authored skills are built.

Draft and published

An Agent has a draft and, once you've published at least once, a current published version. The draft is what the agent editor shows you — persona, model, and context edits autosave to it continuously. A published version is immutable and never changes underneath you; an Agent has at most one current published version at a time, and unpublished draft edits change nothing at runtime until you publish again.

This is the load-bearing mental model for everything downstream: chat sessions and workflow dispatches always run the current published version, never the draft, no matter how far the draft has since drifted.

Who the Agent runs as

Every dispatch — a chat message, or a Workflow's agent step — runs the Agent with one workspace member's connected credentials. This "Run as" control lives on the Agent itself, not per-workflow: an agent step delegates to the Agent as-is, equipment and identity included, and can't override either. See sessions & runs for how a run uses that identity once it's underway.

Publishing and versions

Publishing an Agent compiles its definition — persona, model, context — into a real eve agent project, runs the build, and uploads the resulting artifact to object storage. The artifact is cached by a content hash — a digest of the definition, the resolved model and reasoning effort, the compiler version, the pinned eve version, and the build environment, keyed to the Agent's own identity so that two Agents are never confused for one, even if you give them the same name and the same definition.

That hash has two practical consequences. An identical definition never rebuilds — republishing an Agent whose draft hasn't meaningfully changed reuses the existing artifact. And a workspace preset edit changes nothing already running: it only takes effect the next time the Agent publishes, because the resolved model and effort are baked into the hash at publish time, not read live.

Each published agent version is immutable and independently addressable on the worker pool. Versions matter because runs are bound to them: a session pins the exact agent version it started with, so editing and re-publishing an Agent never changes the behavior of conversations already in flight — new versions apply to new sessions. See sessions & runs.

Renaming, deleting, and dependents

Renaming is the safe case. Because a Workflow's agent steps delegate to an Agent by reference rather than by name, editing the name in the agent editor's header renames it everywhere at once and breaks no binding.

Publishing state is where dependents get interesting. An agent step needs its Agent to have a published version — that's checked when the Workflow publishes. If the Agent is later unpublished or otherwise stranded, the workflow editor surfaces a staleness warning on the published Workflow rather than silently letting runs break: the Workflow still fires, but that agent step fails at run time until the Agent is published again.

Deleting an Agent is the stricter case: it removes the Agent and every published version, so it's blocked outright while any published Workflow still binds it in an agent step, or any chat session still exists against it — the error names the Workflows in the way. A draft Workflow referencing it doesn't block the delete; the draft just gains a diagnostic naming the missing Agent the next time it's validated.