Skip to main content

Concepts

A handful of words explain the entire product.

Agent Space
└── Agent
    ├── Draft          (you edit)
    ├── Version        (immutable, published)
    │   └── Active in  development · production
    ├── Triggers       manual · schedule · HTTP address · another agent
    └── Runs           durable, auditable

Agent Space​

The space is where agents live inside your organization. It defines:

  • who can build, publish, and administer there;
  • what the agents in that space can reach — allowed tools, skills, connections, and addresses;
  • the ceilings on time, iterations, and depth that a definition may declare.

See Spaces and access.

Agent​

A versioned definition of behavior: the steps, the data going in and out, the limits, and the identity it runs under.

Flow, step and component​

The flow is the steps wired to one another — that is what executes.

A step is an instance of a component: query a database, call an API, send email, decide, wait, write. The component is the type, and it comes from the product's catalogue.

You do not invent components: what is not in the catalogue does not exist for the flow. When a step refuses the field you want to configure, it is the wrong component — and that is not fixed by configuring it.

See Step types and System components.

Connection​

A server plus a credential, registered once, under a name of its own. Steps point at the connection by name; the secret stays in the vault and never shows up again — not in the edit screen, not in the published definition, not in the conversation.

See Connections.

Draft​

The agent being edited. It is yours to work on: saving affects nothing that is running.

Two people editing the same draft do not silently overwrite each other — the second save is refused with a conflict warning, rather than erasing the first person's work.

Version​

Publishing creates an immutable version. It never changes: not by editing, not by credential rotation, not by mistake.

Each version has a semantic number (1.2.0), chosen by you, unique within the agent.

That is what underpins the product's most important promise: what was tested is what runs.

Environment​

A version is active in an environment:

EnvironmentFor whatWho can
developmentTesting for real, with real runsPeople who build
productionRunning for realPeople who publish

At most one active version per environment. A new activation deactivates the previous one — and the history remains.

Going from development to production is called promoting, and it promotes exactly the same version — not a rebuild of it. See Promoting and rolling back.

Trigger​

The way a run is started:

TriggerWhen to use
ManualSomeone triggers it from Studio or over the API
ScheduleFixed times, with a time zone
HTTP addressAnother system calls, with its own credential
Another agentOne agent calls another as part of its flow

Every trigger points to an exact active version — never to "the latest". Publishing a new version does not by itself change what a schedule runs: what happens is that the previous version stops being active.

See Triggers.

Run​

Every trigger creates a run: an object of its own, with frozen input, a step-by-step timeline, output, and outcome.

Three properties always hold:

  • Durable. It survives restarts and resumes where it stopped.
  • Frozen. The definition is photographed at the moment of triggering. Editing the agent during a run does not affect it.
  • Auditable. Who asked, how it was triggered, and under which identity it ran are recorded separately.

See Following runs.

The run's identity​

Three different things, never mixed:

AxisWhat it is
Who askedThe person who triggered it, or the run that called it
How it was triggeredManual, schedule, HTTP address, another agent
Which identity it ran underAlways the organization's service account — never yours

The third item is what lets a schedule run at three in the morning without depending on your session being alive. See Service account.

Next steps​