Glossary

A common vocabulary to understand Shara’s documentation, organized into topic blocks. Each term links, where applicable, to the guide where it’s covered in depth. Missing a concept? Write to us at support@aiginer.com.

The glossary is split into blocks: consumption and billing, agents and orchestration, models, security and control, integration (API, webhooks, connectors) and operation (multi-tenant, auditing, licensing). Terms marked with a link have a dedicated guide; the rest are defined here in a self-contained way.

Consumption and billing

Shara bills for abstract consumption: you never pay for “a provider’s tokens”, but for a single, stable unit of your own. This decouples your invoice from the specific model used underneath and from market price changes.

Term	Definition
STU (Shara Token Units)	The client’s single unit of consumption, independent of the model used underneath. 1 STU = 1 weighted token: output weighs more than input, and more capable models weigh more per token. All agent activity (reasoning, tool calls, generation) is counted in STU. You pay STU, not a specific provider’s tokens. See STU and quotas.
Quota	The volume of STU included in your plan each monthly cycle. While you consume within the quota there are no extra charges. The quota renews at the start of each billing period.
Overage	STU consumed above the monthly quota on the cloud plans, billed at €5 per million STU. Concerto Local has no overage. To limit it, you can edit the spending caps.
Rollover	Carrying over unconsumed STU to the next month, with a cap of 20% of the base quota. Carried-over STU expire after 2 months. It applies only to cloud plans; Concerto Local has no rollover because its cloud quota is a fixed bag. Details in STU and quotas.
Saving mode (low-spending)	A mode that automatically lowers the model alias one step (Symphony to Sonata, Sonata to Prelude) outside your business hours on the cloud plans, and also from 130% of your quota. Concerto Local never lowers its model.
Self-paying API	The mechanism by which Shara pays for model usage on your behalf and presents it to you consolidated in STU. You don’t manage provider keys or external balances.

Mental rule: quota is what you’ve already paid, overage is what you pay extra if you go over, and rollover is what you rescue from a slow month. The spending caps are the brake that prevents surprises.

Agents and orchestration

Shara isn’t a single chatbot: it’s a team of specialized agents coordinated by an orchestrator. Each person talks to the agent that fits their role, and Amadeus coordinates between them. See Agents.

Term	Definition
Amadeus / orchestrator	The agent that coordinates the team. It receives a request that crosses several departments, decides which specialists get involved, delegates and consolidates a single response. It’s on every plan. Owners and administrators talk to it directly; each employee talks to the agent for their own department.
Departmental agent	Each of the 20 specialists (Wanamaker, Patterson, Graham…) covering an area of the company (sales, support, finance, legal, etc.). Your plan decides how many you have: you choose 5, 10 or 15 of the 15 selectable agents (First, Pro, Max), and 5 more can be added from Max. See Agents.
escalate_to_amadeus	The escalation tool: when a departmental agent detects that a request exceeds its scope or needs another department, it hands it back to Amadeus. Coordination between agents always goes through Amadeus.
Run	An individual execution of an agent: a call with its input, its context, the tools it uses and its output. Every run is counted in STU and recorded. A single conversation can create several chained runs.
IDENTITY.md	The corporate identity (tone, values, brand rules, do/don’t) that is added to every task. It changes by incremental patch (rules are added or one section is replaced) and never by full replacement. See Agent identity.
Memory	The notes Shara keeps between conversations, in four scopes: company, department, agent and personal. It is included in every plan. See Memory.
Flow	A reusable, step-by-step automation made of nodes (input, data, AI, logic and output). In the app it appears as Automations. See Flows.
Role	What a person can see, approve and change: owner, administrator, director, operator, IT or viewer. See Roles and permissions.
Approvals	The human approval inbox. Any action with an effect outside Shara (sending an email, paying, changing external data) stays pending your sign-off. If nobody decides, the conversation stays on hold for up to 7 days; after that the request expires and the action does not run. See Approvals and audit.

Models (aliases) and no lock-in

Shara never exposes the real provider behind a model. It works with stable aliases that abstract power and cost, so we can swap providers underneath without your integration or your invoice ever knowing. See No vendor lock-in.

Alias	What it’s for
Prelude	Light and cheap tier. Fast tasks, classification, simple extractions, short replies. The cheapest in STU. Available on every plan.
Sonata	Balanced tier. The workhorse for most office tasks: drafting, summaries, standard support. Available from Pro.
Symphony	High tier. Complex reasoning, multi-step analysis, tasks that need more context and precision. Available from Max, and in the hybrid mode of Concerto Local.
Concerto	The model that runs locally, on the Concerto Local plan (on-premise). It is a single, top-tier model that runs on your server. Local inference does not use the cloud quota.

Term	Definition
Model alias	The public name of a model (Prelude, Sonata, Symphony, Concerto). It hides the real provider, avoids lock-in and lets Shara optimize cost and quality without breaking your integration. You never pick a provider. In the app, Shara picks the alias according to your plan, your business hours and your quota. Through the API you pick the alias yourself, up to the ceiling of your plan; asking for a higher one returns 422 alias_plan_mismatch.
No lock-in	The guarantee that you don’t end up tied to a provider. Since you only ever see aliases, Shara can replace the underlying engine with a better or cheaper one without anything changing on your side. See No vendor lock-in.

Security and spending control

Control isn’t optional: Shara is designed so that nothing important runs without supervision and spending never spikes without a brake. See Security and compliance.

Term	Definition
Spending caps (kill-switch)	An automatic, multi-level spending cut: per run, per hour and per day. By default they are 1M, 10M and 80M STU. If an execution (or a chain of them) goes over, Shara stops it and answers 429 kill_switch. An owner or administrator can edit each cap or switch it off. See Approvals and audit.
Audit log	The record of actions in your company: who did what, on which resource, with the before and after. Each record is chained with a SHA-256 hash to the previous one, so a check can detect that an intermediate record was altered. See Approvals and audit.
DPA	Data Processing Agreement (article 28 GDPR). It is the contract that governs how Shara handles data on behalf of your organization. It is included in every plan and signed to measure on Max and Concerto Local. See the DPA.

Integration: public API

The public API is the surface an external developer uses to integrate Shara with their systems. It authenticates with an API key and applies usage limits. See REST API and Connectors.

Term	Definition
API key	The credential that authenticates your calls to Shara’s API. It starts with shara_sk_live_, is issued per workspace, is sent in the Authorization header, can be revoked and rotated, and must never be exposed in client code or repositories. An API key only works on POST /v1/inference and on the MCP bridge; everything else needs a signed-in session.
Rate limit	The request limit per minute that protects the service: 60 per IP and route, and 600 per workspace and route. If you exceed it, the API responds 429.
Idempotency	The guarantee that resending the same request doesn’t duplicate it. You identify the event with a unique id (for example X-SHARA-Event-Id); if Shara already processed it, it returns the previous result instead of running it again.

A call that works today, with an API key:

curl -X POST https://api.sharasaas.com/v1/inference \
  -H "Authorization: Bearer shara_sk_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "alias": "Sonata",
    "agentSlug": "amadeus",
    "messages": [
      { "role": "user", "content": "Summarize the latest support ticket and suggest a reply." }
    ]
  }'

The response already carries the result (content) and how the turn ended (status). All fields are in the REST API page.

Integration: webhooks

Shara does not offer inbound webhooks yet. See Webhooks for what you can do today.

Integration: connectors

Term	Definition
Connector	A specific way to connect Shara with your systems: Desktop Agent, Server Agent and MCP gateway. Each connector brings its own authentication and isolation guarantees. See Connectors.
Universal connector	The overall approach: Shara offers a generic path to integrate systems with no custom development, by combining the connectors above. The universal connectors (Gmail, Outlook, Slack, Teams, Calendar, Drive, Holded and more) are on every plan; HubSpot and Pipedrive are available from Pro.

Operation: multi-tenant and licensing

Term	Definition
Tenant (multi-tenant)	Your client organization. Shara is multi-tenant: a single platform serves many clients with strict isolation of data. Every query is filtered by company, and in thirteen areas (model consumption, billing, approvals, memory reads, runs, flows, integrations, HR, projects, support, tax invoicing, document templates and customers, the CRM) the database adds its own row-level policies. One tenant’s data, API keys and STU consumption never cross over with another’s.
Licensing service	The service that validates the license of Concerto Local. The installation checks it every 24 hours. The licence is valid for 7 days and renewed daily. If it can’t connect, there are 30 days of grace with everything normal and a warning; after that you can only read and export until the connection is back. Licenses are signed with Ed25519, so they can be verified without contacting the server.
Concerto Local / on-premise	Shara’s deployment on your own infrastructure (your own servers or private cloud), instead of the managed cloud, at a custom price. Database, agents and Concerto inference run on your hardware. It has two modes: local only (everything with Concerto) and hybrid (Amadeus uses Symphony in the EU cloud, with a fixed bag of 60M STU per month that you switch on and off from the console, with no overage and no rollover). See Concerto Local.

Looking for a concept in more depth? Start with What Shara is, STU and quotas, REST API or Connectors.