Concepts

A short glossary of the building blocks you'll meet in Stoa, in plain language.

Knowledge bases

A knowledge base (KB) is a single indexed source that Stoa can search: one uploaded document (a PDF, a Word file, or another supported format), or one or more web addresses it reads and keeps in sync. Stoa breaks the source into searchable passages with their original page references intact.

• One document, one KB. Creating a knowledge base attaches exactly one file (or a set of URLs treated as one source). To turn a whole batch of documents into knowledge bases in one step, each named and described automatically from its contents, use bulk upload instead of creating them one at a time.
• Permissions are per-KB. You can grant read or admin rights to specific roles or users. A user only sees the KBs they're allowed to see.
• Citations are mandatory. When an answer references a KB, it names the exact source and passage. Verifiable, never hallucinated.

Agents

An agent is a specialized assistant with its own job description and toolkit. Think of it as a virtual colleague trained for a specific role.

An agent has:

• A name and description so users know what it does.
• Instructions that shape its tone, format, and guardrails.
• One or more knowledge bases it can search.
• Skills and tools it's allowed to use.
• Permissions controlling who in your org can talk to it.

You don't write code to create an agent. You write a few sentences of instructions, attach the relevant KBs, and the agent is ready.

Skills

A skill is a reusable capability with no model of its own: a set of instructions and knowledge bases that gets folded into whichever agent is given it as a tool. You create one from the Agents screen, the same way you create an agent, just with its type set to Skill instead of Standalone.

You don't talk to a skill directly. An agent that has been given a skill can call on it the same way it might call a database lookup, pulling in the skill's instructions and knowledge for that turn. This keeps a repeatable piece of know-how, a report format, a comparison method, a house style, out of every agent's own instructions and in one place your team maintains once.

Examples of what a skill might package:

• "Summarize this contract against our standard policy and flag deviations."
• "Draft a Q3 progress report from the data in the operations KB."
• "Compare these two policies and produce a side-by-side table."

Tools

A tool is something Stoa can do beyond text generation: query a database, call an internal API, trigger a webhook, read or write a file, look up a record. Tools run inside your network and are configured by your administrators.

Stoa supports both standard tool protocols and custom-built connectors. If your internal system doesn't speak a modern API standard, we can build a tool that bridges it. Tools have their own permissions: an admin chooses which agents (and which users) are allowed to call which tools.

Workflows

A workflow is a guided, multi-step procedure for a routine request, built once (usually by an admin or a power user) and reused by your team: onboarding a new starter, triaging an access request, filing a ticket. Each step can be a chat turn, a tool call, or another workflow.

A workflow can drive itself forward through its steps without anyone approving each one, and pause partway through to ask a specific person to approve a step before it goes ahead, filing that ticket, for example. Workflows are private to their owner until shared, and every run is tracked so an approver can see what happened and step in when something is waiting on them.

Schedules

A schedule turns a prompt or a workflow into something that runs itself on a cadence you set (daily, weekly, whatever the task needs) instead of waiting for someone to ask. Each run's output collects in its own conversation, so a recurring brief or a nightly check is there waiting for you rather than something you have to remember to run.

Chats

A chat is a conversation between a user and Stoa. Every chat runs in one of four modes:

• Auto, the default: Stoa decides per message whether the question needs reasoning first.
• Instant, for a quick answer with no reasoning step.
• Thinking, which reasons before answering every time.
• Research, for in-depth questions that need the full deep research pipeline. Chosen per request; a chat falls back to its ordinary mode on the next message.

Chats keep history, support follow-up questions, and let users react with thumbs up or thumbs down to feed the feedback loop.

Deep research

Deep research is a multi-step pipeline for questions that need a real research process, not a one-shot answer. The pipeline:

1. Scopes the question.
2. Plans the structure of the answer.
3. Researches each section against your knowledge bases.
4. Identifies gaps.
5. Drafts a structured response.
6. Critiques its own draft.
7. Revises until quality gates pass.
8. Optionally requests human approval before finalizing, at more than one point along the way.

The output is a structured brief with citations, suitable for grant proposals, policy briefs, evidence syntheses, and similar work.

Report shapes

A report shape is a template for the kind of report deep research can write, a policy brief, an evidence synthesis, a donor report, whatever shapes your organization has defined. Deep research picks a shape to match the question being asked, and the shape guides how the plan and the final draft are structured. Administrators define and edit the available shapes.

Citations

Every answer Stoa produces from a knowledge base includes citations: a small tag naming the source document and page right next to the claim it supports, plus a "Sources" list below the answer with the source, page, and a short excerpt for every passage used. Citations are not optional and not generated, they're computed from the actual retrieval.

Permissions

Stoa uses role-based access control at a granular level. Permissions follow a resource:action shape (for example, the right to view knowledge bases or to create agents). Roles bundle permissions, and you can define custom roles. Permissions can target individual resources, so a user might have full access to one KB and read-only access to another.

Audit log

Every meaningful action in Stoa is recorded in the audit log: who did what, when, from where, and against which resource. The log is searchable, filterable, and exportable for compliance reporting.

Where to next

• New users: continue to the User Guide.
• New admins: continue to Installation.
• Integrating Stoa with your systems: see Custom tools.