Skip to content

Architecture

The engineering picture — what the system is made of, and how a single request travels from a click to a finished, logged piece of work.

The shape of the system

Three surfaces, one backend. The web portal, the REST API and the Telegram bot are all thin entry points — the agents, the intelligence services and your data live in a single backend behind them.

Web portal
REST API
Telegram
Backend — API server & agent runtime

Authentication, agent loop, tool execution, intelligence services

PostgreSQLYour data
Task queueScheduled work
Model layerLLM providers

The pieces

API server
The single entry point. It authenticates every request, resolves which business it belongs to, and routes the work to the right agent or service.
Agent runtime
Runs the agent loop — assemble context, call a model, execute the tools the model asked for, repeat until the task is done or hits an approval gate.
PostgreSQL
The system of record — businesses, leads, campaigns, documents, invoices, decision trails. Every business's rows are isolated.
Task queue
Background and scheduled work — daily briefings, signal sweeps, campaign analysis — runs through a queue, separate from live requests.
Model layer
A provider-agnostic layer over several LLM providers. It routes each call by task class and fails over automatically if a provider degrades.

A request, end to end

Take a concrete task — “find prospects and draft a cold-email campaign.” Here is the full path it travels:

  1. 1
    Entry & authentication
    The request arrives from the portal, the API or Telegram. The API server verifies the caller and resolves which business this is — every downstream query is scoped to that one tenant.
  2. 2
    Routed to an agent
    The work is handed to the right agent — here, Marketing Senior — and the agent runtime starts its loop.
  3. 3
    Context assembled
    Before any model call, the runtime injects the business brain — archetype, profile, voice, knowledge base — plus any high-priority messages waiting in the agent's mailbox.
  4. 4
    The agent loop
    The model is called; it asks to run tools — research prospects, draft copy; the runtime executes them and feeds the results back. This repeats until the task is complete.
  5. 5
    Approval gate
    The campaign is ready to send — an outward, irreversible action — so execution pauses. This gate is enforced in code; the agent cannot pass it on its own.
  6. 6
    Execution
    You approve. The runtime sends the campaign through the email service and writes every action to the decision trail.
  7. 7
    Learning, later
    Hours later, a queued job reads the campaign's results and feeds the lessons back into the business brain — closing the loop.

Multi-tenancy & isolation

Rigyx is multi-tenant — many businesses on shared infrastructure — but each business is fully walled off. The tenant a request belongs to is derived from its authenticated identity, never from anything the caller can set freely, and every database query is scoped to it.

Isolation by construction
An agent only ever sees one business's data. Provider API keys are encrypted at rest. Every query a request makes is limited to the business its signed-in identity belongs to.

Staying up

Two design choices keep the system dependable. The model layer tracks each provider's health and fails over to a healthy one when a provider degrades — a single provider outage does not stop work. And autonomous services never fail silently: if a background job breaks, you are told, rather than discovering it from missing results.

Where to go next
That is the platform. For building on it, head to the developer overview — the full API reference lands in these docs next. To go hands-on, start with how it works.