Skip to main content

Glossary

All the building blocks of ORQO in one place. Terms are grouped by category and build on each other — start with Essentials and work your way down.

Essentials​

The fundamental building blocks you'll work with every day.

Project​

A workspace that groups everything related to a particular goal: Teams, Workflows, Tools, and documents. Projects are how you organize different initiatives.

Team​

A collection of Agents that work together. A team has a shared LLM configuration (which model and API key to use). Agents inherit the team's LLM configuration by default, but can override it with their own — meaning a single team can mix models from different providers. A Claude agent can collaborate with a GPT agent and a Llama agent in the same workflow.

Agent​

An individual AI worker within a team. Each agent has:

  • A role — a description of what it does (e.g., "Research Analyst", "Editor", "Code Reviewer").
  • A perspective — the identity and behavioral guidelines that shape how the agent thinks and communicates.
  • Skills — the tools and capabilities it can use during execution.
  • LLM configuration — inherited from the team, or overridden per agent.
  • Context window settings — how aggressively the agent compacts its conversation history.

The LLM configuration is the fuel, not the identity. An agent's role, skills, and behavior stay the same — you can swap the underlying model at any time. Run a few workflows with GPT-4o, then switch to Claude Sonnet to compare results, without reconfiguring anything else.

Workflow​

An ordered sequence of Stages assigned to a team. When you run a workflow, the platform executes each stage in order, passing context forward.

Stage​

A single step within a workflow. Each stage has:

  • Agent assignments — which agents from the team participate, in what order, and in which phase (start, default, or completion).
  • Task description — what the agents should accomplish in this stage.
  • Hooks — entry and exit hooks that run when the stage begins or ends.
  • Outcomes and routing — define possible outcomes for a stage and route the workflow to different stages based on the result, enabling branching and looping.

Stages aren't just linear steps — with outcome routing, a workflow can branch, loop back, or skip ahead based on what the agents produce. See Workflows for details.

Workflow Run​

A single execution of a workflow. Tracks status (pending, running, completed, stopped, error), timing, and per-stage results. You can browse run history per project or per workflow.

Execution​

How workflows run, communicate, and stay efficient.

Heartbeat Loop​

The execution mechanism within a stage. Agents take turns in assignment order, each getting a full turn to think, use tools, and share findings before yielding the floor. The cycle repeats until all agents signal task completion.

Side Conversation​

A focused exchange between two agents that breaks out of the main round table. The rest of the team pauses while two agents go deep on a specific sub-problem, then the round table resumes. Only the participating agents spend tokens on the exchange.

Context Compaction​

A multi-layer system that progressively compresses conversation history so agents can run indefinitely without hitting context window limits. Each agent compacts independently, with presets ranging from Aggressive to None. See Context Compaction for details.

Hook​

An automated action that executes at stage boundaries. Entry hooks fire when a stage begins (fetch data, initialize a runtime). Exit hooks fire when a stage ends (validate output, send notifications, request approval). Hooks run deterministically — no LLM cost.

Outcome​

A possible result that a stage can produce (e.g., "approved", "needs revision", "escalate"). Outcomes drive routing decisions.

Outcome Routing​

Maps stage outcomes to target stages, enabling branching, looping, and conditional logic in workflows. Combined with loop guards (max visits per stage), this turns linear workflows into adaptive pipelines.

Approval Gate​

A blocking checkpoint where the workflow pauses until a human or external system responds. Implemented via a blocking exit hook — the response drives outcome-based routing. See Human-in-the-Loop.

Trigger​

An automated schedule that executes a workflow at specified times (cron-based). Set up a trigger and the workflow runs daily, weekly, or on any custom schedule without manual intervention.

Template​

A pre-built workflow blueprint from the Template Library. Templates come with everything — agents, stages, routing, hooks — and include a sample run so you can review the output before spending tokens. Install one and it becomes a fully independent copy you can modify.

Artifact​

A structured deliverable produced by agents — rendered as interactive HTML or exportable PDF. Artifacts are polished outputs like reports, analyses, or dashboards that go beyond plain text responses.

Capabilities​

Tool → Skill → MCP Server → App

How agents interact with the world — from a single function to a full integration. Each level builds on the previous one, stepping up when the simpler option isn't enough.

Tool​

The atomic unit of capability — a single function an agent can call. A tool has typed parameters, a credential if it needs to authenticate, and returns a result. You can build tools in the browser or let the Tool Builder write them for you. When a single tool is all you need, this is the simplest path.

Skill​

When a single tool doesn't cut it, you package multiple tools into a Skill. A Skill is a self-contained capability bundle that gives an agent everything it needs for a specific job — tools, credentials, knowledge, and an optional Runtime. Assign a "Slack" skill and the agent gets the Slack tools, the API credential, and the knowledge of how to use them. Skills are the unit of capability.

MCP Server​

When Skills can't cover the requirements — because you need to connect to an external system that discovers its own tools dynamically — you connect an MCP Server. ORQO discovers available tools from the server and makes them available to agents. This is how agents interact with databases, APIs, file systems, and other external systems.

App​

When an MCP server isn't enough — because you need OAuth, webhooks, channel routing, or message delivery — you wrap it in an App. An App is still an MCP server at its core, but widened with the infrastructure a real-world integration needs: authentication flows, inbound/outbound message handling, credential management, and marketplace distribution. Apps handle both inbound messages (receiving events from external platforms) and outbound delivery (sending agent output back). This is how ORQO connects to Slack, WhatsApp, Telegram, email, and any custom service.

Knowledge​

How ORQO organizes, stores, and retrieves information.

Document​

A piece of content uploaded to a project — PDFs, DOCX, web pages, or text. Documents are automatically parsed and flow into the Knowledge Curator for classification.

Document Source​

An external connection that automatically populates a project's document library — GitHub repos, Google Drive folders, APIs, web feeds, or directories on your local machine via the ORQO Desktop App. Sources sync on a schedule so your knowledge stays current.

Knowledge Curator​

The invisible gatekeeper between raw content and structured knowledge. The Curator works automatically behind the scenes — you never interact with him directly. He evaluates incoming content, strips boilerplate, extracts substantive material, and routes it to the Knowledge Graph for classification. See Knowledge Curator.

Knowledge Graph (Long-Term Memory)​

A typed, semantically structured network of classified knowledge. Content is organized using a formal classification ontology — 54 knowledge types across 4 classes, connected by 48 typed relations. Agents navigate the graph following relationships like "broader", "deeper", "consequences", "why" to find contextually relevant knowledge. The graph grows over time as workflows run and agents discover new information. See Long-Term Memory.

Public Chatbot​

An embeddable knowledge assistant that answers questions from a project's Knowledge Graph. Public chatbots serve your clients and external users — no authentication required. See Public Chatbot.

Resources​

Credential​

An encrypted secret stored in your organization — API keys, OAuth tokens, SMTP passwords, SSH keys. Credentials are injected automatically when a workflow runs, so agents and tools can authenticate with external services.

LLM Configuration​

Links an LLM Model (e.g., gpt-4o, claude-sonnet-4-20250514, gemma4:latest) with a Credential (your API key for that provider). You assign LLM configs to teams or to agents directly to fuel them with intelligence. ORQO supports cloud providers (OpenAI, Anthropic, Google, OpenRouter), local inference (Ollama, LM Studio), and custom endpoints. See LLM Providers.

Runtime​

An execution environment where agents run tools that need file access or shell commands — your own SSH server, a Daytona cloud sandbox, or a directory on your local machine via the ORQO Desktop App. Agents never see runtimes; when a tool runs, the platform routes the command to the right environment transparently. Runtimes are assigned to Skills or Stages.

Communication​

How ORQO connects to the outside world.

Contact​

A person or service ORQO communicates with. Each contact can have multiple Contact Channels — one per connected App. For example, a contact might have a Slack channel and a WhatsApp channel. Wherever you message the Doorkeeper from, he responds through that same channel. Only registered Contacts can interact with ORQO through messaging platforms — unknown senders are rejected before any AI processing occurs.

Doorkeeper​

Your organization's AI front desk. Doorkeeper receives inbound messages from all connected communication channels — Slack, WhatsApp, Telegram, email, the ORQO dashboard — and decides what to do with them: respond directly, delegate to a workflow, create and manage projects, or route to the right contact. He is equipped with everything required to replace the main dashboard UI functions through natural language conversation alone — and he can hand off to the Workflow Assistant or Integration Builder (which calls the Tool Builder internally) when deeper work is needed. The dashboard's chat drawer picks the right specialist for the page you're on; Doorkeeper is the default on every page that isn't a project, settings → integrations area, or developer portal. See Doorkeeper.

Workflow Assistant​

A project-scoped AI workflow designer. Describe what you want to automate and it builds the workflow, adds stages, assigns agents, wires in tools, validates the result, and can run or schedule it for you. It also analyzes past runs to suggest improvements. The chat drawer opens the Workflow Assistant automatically on any project, team, workflow, stage, or run page; the Doorkeeper can also hand off to it when a request needs workflow design. See Workflow Assistant.

Tool Builder​

An AI software engineer that writes custom Python tools from natural language descriptions. Describe the tool you need, and it writes the code, verifies it through a five-phase pipeline (build, schema, instantiate, execute, log preview), runs a security scan, and saves the finished tool to your Tool Library. The chat drawer opens the Tool Builder automatically on Developer Portal pages; it is also called internally by the Integration Builder whenever an integration needs Python. See Tool Builder.

Integration Builder​

An organization-level AI that helps you add new platforms (Stripe, Notion, Slack, and more) to your ORQO organization. It plans the work, researches the platform, decides the right integration shape (MCP / native tool / App / bundle), delegates any Python coding to the Tool Builder, bundles the result into an installable Skill, and optionally publishes it — privately, via link, or to the public marketplace. The chat drawer opens Integration Builder automatically on Settings → Integrations, MCP Servers, Credentials, and Apps pages. The Workflow Assistant routes its capability requests through Integration Builder rather than calling Tool Builder directly. See Integration Builder AI.