Architecture

Shara is organized into four layers: Client, API, Orchestration and Data. Every request goes through all of them, with double-layer isolation between clients, an orchestrator that decides which specialist and which model resolve each task, and a governance layer that keeps a person in the loop for what matters.

The four layers

Layer	What it does
Client	The only thing you install. Desktop App, Server Agent and universal connectors.
API	Authenticated entry point. Applies tenant, rate limits and strict headers.
Orchestration	Amadeus plans, delegates to the specialists and a selector picks the model tier.
Data	Postgres with double-layer multi-tenant isolation.

The core idea is the same one the diagram on the home page illustrates: you speak in natural language, Amadeus plans and distributes the work, the departmental specialists resolve it using your connected tools, and you get a consolidated, traceable result. Underneath there is isolation, governance and model engineering, but from where you stand it all comes down to asking and receiving.

The flow of a request, layer by layer

The best way to understand the architecture is to follow a request from the moment you write it until you get the result. Imagine you tell Amadeus: “Prepare this week’s support close-out and propose a follow-up email to the three clients with the most incidents.” This is what happens underneath:

1. You write in natural language. Your message enters through the API behind a signed token. The isolation layer fixes your organization as a mandatory filter: from here on, no other client’s data is accessible.
2. Amadeus plans. Before reasoning, your company’s identity (tone, values, rules) is injected. Amadeus analyzes the request, breaks it down into tasks and prepares a plan with what it intends to do.
3. Amadeus delegates. It hands each task to the right specialist with just the right context, without leaking data between agents. The support summary goes to Wanamaker; the commercial email leans on Patterson if there’s a sales opportunity.
4. The specialists resolve. Each departmental agent works its part with the knowledge of its area.
5. They use your tools via connectors. The agents read from your integrations (helpdesk, CRM, email) with permissions delegated via OAuth. Reading is direct; writing requires your approval.
6. Amadeus unifies. It gathers the specialists’ results into a single response in your tone, along with the actions awaiting your sign-off.
7. You get a traceable result. The whole chain is left in the audit log (who asked for what, which agent resolved it, which model was used, before and after) and consumption is counted in STU.

What you receive isn’t just the text: it’s the text, the proposed actions and the trail of how it was reached. That traceability is what turns an AI response into something you can audit, defend to a client and improve over time.

1 · Client

It is the only thing you install, and it is universal across all plans:

• Desktop App (an Electron app for Windows, macOS and Linux): native notifications, shortcuts and approvals panel. It is the recommended client for day-to-day use.
• Server Agent (headless daemon): for server environments with nobody at the screen; the agents read the server through it and its changes wait for an administrator’s approval. Flows don’t launch themselves: today they run with the Run button or by asking Amadeus.
• Universal connectors (Gmail, Slack, CRM, ERP, etc.) that expose your tools as team capabilities. The catalog is in Connectors.

2 · API

Every request goes through api.sharasaas.com and an isolation layer that extracts your organization and injects it as a mandatory filter before touching the database. On top of that:

• Signed JWT with short expiry and secure refresh. Optional two-step verification, enforceable for the whole company; whoever turns it on needs it across the whole application.
• Rate limiting per IP address and per company (not per API key).
• Structured logs with no personal data in the clear.
• Strict headers: HSTS, CSP and X-Frame-Options.

3 · Orchestration

It is Shara’s brain and it has three moves: plan, delegate and unify. Amadeus analyzes the request, decides which agent or agents resolve it and delegates while keeping the context, without leaking data between them. When the specialists finish, Amadeus gathers their outputs into a single response consistent with your tone.

Two key pieces act in parallel: a mode selector picks the model tier according to time of day, urgency and available quota; and an output redactor reviews the response before returning it to prevent leaks, for example the real provider behind an alias. Departmental agents only talk to their own area; coordination between departments always goes through Amadeus.

4 · Data and multi-tenant isolation

Shara never mixes data between clients. You should know exactly where that isolation is enforced, because not every platform tells you:

• In the application, on every query. Every query carries your organization as a mandatory filter, enforced before touching the database. It is not a courtesy check: it is the mechanism that isolates the data.
• In the database, as a second barrier in thirteen areas. For model consumption, billing, approvals, reading of memory, runs, flows, integrations, HR, projects, support, tax invoicing, document templates and customers (CRM), the database also applies its own row-level security policies (RLS). In those areas isolation is enforced twice, independently.

Concerto Local uses exactly the same architecture model, but the database and inference live on the client’s infrastructure. It can run 100% locally; in hybrid mode the plan includes an optional 60M STU/month cloud bag for Amadeus, which you switch on and off from the console. Read Concerto Local.

The governance layer

Across the four layers there is a cross-cutting layer that maintains human control and spending safety. It is not an extra: it is part of the product, and it is what sets Shara apart from a loose assistant. It consists of five mechanisms.

Approvals

Any action with an effect in the world (sending an email, issuing an invoice, modifying a record) doesn’t run: it is generated as a proposal and lands in your approvals inbox. You review it, edit it if you want and approve or reject it. An approval can’t be resolved by a bot: it requires a credential tied to a person. The human in the loop is a design guarantee, not an option.

Spending kill-switches

Shara carries automatic spending cuts that stop activity if consumption spikes, without penalizing normal use:

Cap	Default
Per run	1M STU
Per hour	10M STU in the last 60 min
Per day	80M STU in the last 24 h

If any of these thresholds is reached, Shara stops on its own and notifies the administrator. An owner or administrator can edit the values or switch any cap off. The windows are rolling and the cuts lift on their own when consumption drops; an administrator can lift them earlier. It is the safety net so nothing runs away while the team works in the background.

Output redactor

Before returning a response to you, a redactor reviews it to prevent leaks: the real provider behind a model alias must never escape, nor sensitive data out of context. You always work with the public aliases (see No lock-in); the real provider is irrelevant to your day to day and stays confidential.

Audit

Every action with an effect is left in a queryable audit log: who asked for it, which agent resolved it, which model was used, and the before and after of the change. That end-to-end traceability lets you justify the work to a client or an inspection, and also review and improve how your team works.

Self-paying: cost tied to each action

Every call to a model is counted at the moment it happens and tied to the organization that originated it, so consumption is measured action by action. That makes cost predictable and traceable: you know what was consumed, by whom and on which task, all expressed in the same unit, STU.

Memory: identity and semantic memory

Agents don’t start from scratch in every conversation. Their behavior rests on two complementary kinds of memory.

The corporate identity lives in an IDENTITY.md file per agent: tone, values, rules and restrictions. It is injected at the start of each task, so everything the team produces comes out in your voice and not a neutral factory one. It isn’t rewritten all at once: it evolves through versioned patches, and each patch is logged in the audit, so you can fine-tune behavior safely and roll back if needed.

The semantic memory retains your company’s living knowledge (what your products are called, who your key clients are, how you write) and retrieves it when it is relevant to the task at hand. It is what makes the team adjust to your way of working the more you use it, always within your organization and without crossing data with other clients.

• Identity: each agent’s “how I should behave”. Stable, versioned, editable by you.
• Semantic memory: the “what I know about this company”. It grows with use and is retrieved by relevance.
• Both are scoped to your organization by multi-tenant isolation: one client’s memory never reaches another’s.

The four model tiers

In the app, Shara decides the model for each task according to your plan, your business hours and your quota. Through the API you choose the alias yourself, up to the ceiling of your plan. Either way you work with four public aliases, and the real provider behind them is irrelevant to your day to day (see No lock-in).

Tier	What for	Availability
Prelude	Fast and economical. Simple tasks and night saving mode.	All plans
Sonata	Balanced. Default option in most conversations.	Pro and above
Symphony	Maximum capacity, for complex tasks. Used by Amadeus on Max and above.	Max and above, and Concerto Local in hybrid mode
Concerto	Local engine deployable on the client’s infrastructure.	Concerto Local

How the right model is chosen

The mode selector decides which tier resolves each step, looking for the balance between quality, cost and speed. It isn’t a fixed choice per conversation: within a single task, some steps can go on an agile tier and others on a maximum-capacity one. It weighs these factors:

• Working hours. Outside your hours, a saving mode drops a tier automatically to reduce cost without affecting what matters.
• Available quota. The selector takes your STU bundle into account so it doesn’t spike on tasks that don’t require it.
• Plan hired. Full Symphony is in Max and above; Prelude, in all plans, and Sonata, from Pro.

The result is that you pay for high-end capacity only when the task calls for it, and for lightness when that is enough. All of this happens transparently: you describe what you need and the system assigns the right engine to each step.

What STU are

The STU (Shara Token Units) is the platform’s single unit of consumption: 1 STU = 1 weighted token. Instead of mixing tokens from different models, per-provider prices and technical units that change, all of the agents’ work is measured in the same currency: STU. Output weighs more than input and more capable models weigh more per token, so cost is comparable and predictable whichever model is used.

Each plan includes a monthly STU bundle; if you exceed it on a cloud plan, the overage is charged at €5 per million STU (Concerto Local has no overage), and you can grow the bundle from Max, with an additional agent (€99/month, +15M STU). Consumption is counted action by action and reflected in the audit, so at any moment you know how much you have spent and on what. The detail is in STU and quotas.

Want to continue? See the agent catalog to meet Amadeus and the 20 specialists, Security for isolation and approvals in detail, or No lock-in to understand why you work with model aliases.