Skip to main content

Core Concepts

This page defines the vocabulary used throughout the docs and the builder. Skim it once now, and come back whenever a term needs pinning down.

Tools​

A tool is the smallest building block of automation — a function. Every tool has a name and description (agents read these to decide when to call it), a tool type that determines how it executes (AutessaScript, API call, LLM call, database query, connector actions, and more), and a typed configuration specific to that type.

Tools declare arguments — the inputs an agent fills in when calling the tool, each with its own description. Private arguments are collected directly from the user, never passed through the LLM and never stored in any history — use them for sensitive values like card numbers. See Tools and the tool type catalog.

Agents​

An agent is an LLM worker: instructions (its system prompt), an AI model, and a set of attached tools it may call. The agent decides which tools to invoke and in what order based on the request. Agents come in four types:

  • Simple — you pick the tools.
  • MCP — automatically uses the tools of an MCP server.
  • Critic — self-evaluates its output against your criteria and refines it over bounded iterations.
  • Search — queries an AutessaDB knowledge base with semantic search.

See Agents.

Managers (multi-agents)​

A manager orchestrates a pool of agents. Its instructions describe delegation rules — which agent handles what, in what order, and how to synthesize results — and its model makes those calls at runtime. Managers appear in the builder as Multi-Agents. See Multi-Agents.

Versions​

Every publishable resource (tools, agents, managers, apps) has a draft and any number of released versions. Version states are DRAFT, PUBLISHED, and ARCHIVED:

  • Work in the draft sandbox never affects customers — API calls default to the published version.
  • Publishing promotes the draft to the published version; it requires PUBLISH or ADMIN access on the resource.
  • Rollback repoints the published version to any prior archived version, taking effect immediately, while you keep iterating in the draft.

See Versions.

Variables — @@{variable}​

The placeholder syntax @@{name} inserts values at runtime, in tool configurations and in agent/manager instructions. It resolves three kinds of values:

  • Environment variables — company-stored secrets and settings (below).
  • Prompt template variables — placeholders you declare on an agent or manager (for example customer_name) and supply per invocation, in the test panel or as promptTemplateVariables in API calls.
  • Built-in variables — always available without any setup: @@{currentDate} resolves to the current UTC date ("January 8, 2026") and @@{currentTime} to the current UTC time ("2:30 PM"). Handy for prompts like Today is @@{currentDate}. Your own variables win on a name clash — a built-in never overrides a value you supplied. See the full list in Environment Variables.

Environment variables​

Environment variables store sensitive values — API keys, secrets, configuration — securely at the company level. Tools and agents reference them with @@{MY_API_KEY} instead of hardcoding credentials; values are never exposed in agent conversations. See Environment Variables.

Resource IDs​

Every resource has an opaque public ID — a short string like V1StGXR8Z5 — shown in the resource's Details panel in the builder. These IDs are what you use in API calls (the resourceId query parameter) and what appears in any user-visible JSON. Treat them as stable identifiers — never construct or increment them. They are IDs only, not secrets.

Companies and scopes​

Every resource belongs to exactly one company, and you always work inside one company at a time — your active scope. Switching scope re-scopes the entire builder and APIs to that company's resources, members, and limits. You can belong to many companies, including your personal one. See Companies.

Sharing and access levels​

Within a company, each resource is private to its owner, shared with specific teammates, or company-wide. Grants carry one of four access levels:

  • READ — view and execute the resource.
  • WRITE — edit the draft.
  • PUBLISH — everything in WRITE, plus publish and roll back versions.
  • ADMIN — everything, plus sharing, transfer, and deletion.

The owner always holds ADMIN implicitly, and for most resource types transferring ownership is reserved for the owner alone — ADMIN is not enough (custom apps and voice clones are the exceptions, where any ADMIN can transfer). The levels also mean slightly different things per resource: on an AutessaDB table, WRITE means writing rows; on a custom app, READ means launching it. Each resource's guide page has a Sharing and access levels section with the exact mapping.

Access levels control what teammates can do in the builder. What API callers can do is scoped separately, by the credential — see Authentication.

Where to go from here​

With the vocabulary in place, pick the path that matches where you are:

  • Haven't built anything yet? The Quickstart takes you from a fresh account to a published agent in seven steps.
  • Ready to integrate? Authentication explains API keys, poweruser credentials, and OAuth — everything your code needs to call what you've built.
  • Wondering what tools can do? Browse the tool type catalog — scripts, API calls, LLM calls, database queries, connectors, and more.