Skip to content

Architecture ​

How the agent talks to AIMO ​

AIMO's cloud hosts the web UI and coordinates work. The AIMO agent runs only in your environment, usually as a container you control. There is no network path from AIMO to your database; raw rows do not leave your network. For organizations that need everything inside the perimeter, the whole platform, cloud side included, can be deployed on-prem with an LLM you supply.

  • Outbound session. The agent dials out to AIMO and holds a single long-lived, encrypted connection (a WebSocket over TLS). AIMO never connects in. You do not expose databases or the agent to the public internet for normal operation.
  • Job requests. Over that one channel, AIMO pushes work to the agent as a fixed set of job types (connection tests, schema analysis, profiling, monitor calculation, validation; not arbitrary code). Anything that does not deserialize as a supported job is rejected. See Operations.
  • Aggregates and metadata only. What flows back are structured summaries and monitor outputs: schema descriptions, per-column statistics, monitor values per time block, row counts, validation outcomes, plus progress, logs and heartbeats. Any sampled rows are read and summarized on the agent; the samples themselves do not leave your network.

Inside your perimeter, the agent connects to your database for profiling and checks; that traffic stays local. The agent runs every client-database query in autocommit, asks the database for a read-only session where the engine offers one, and never writes to your data.

AIMO's cloud and your environment: one outbound session from the agent, no inbound path to your database A dark band at the top is AIMO's cloud: the web UI, monitor generation, job scheduling, the detector, episodes and alerts. Below it a panel is your environment, holding the AIMO agent and your database side by side. The agent opens one outbound TLS session to the cloud; over it typed job requests come down and aggregates and metadata go back up. The agent runs bounded, read-only SQL against your database, and the rows stay there. A dashed path from the cloud to the database is crossed out: AIMO has no inbound path to your network or your database. AIMO CLOUD Web UI · monitor generation · job scheduling · the detector · episodes and alerts ONE OUTBOUND TLS SESSION, OPENED BY THE AGENT typed job requests aggregates and metadata only no inbound path YOUR ENVIRONMENT AIMO agent Dials out, never listens. Runs the fixed job types, keeps credentials encrypted, returns aggregates. Your database A read-only role. Rows are read and summarised here and never leave. bounded SQL read-only
Isolation by design: AIMO never connects to your database; only aggregate data crosses to the cloud.

End-to-end flow ​

This matches Getting started step by step:

  1. Sign in. The web UI, hosted with AIMO's cloud, for agent registration, connections, analysis and the tables you monitor.
  2. Register an agent. Pair the agent with your account using a registration token; the CLI writes the identity material and aimo_agent.sh. See Registration.
  3. Add database credentials. Secrets go through the agent, not the browser: ./aimo_agent.sh add, or python -m aimo.agent.cli with the same environment. The agent encrypts them locally before they are stored; AIMO holds only the ciphertext and ships it back in each job payload for the agent to decrypt on its side at run time. See Agent CLI.
  4. Run the agent process. A long-lived start process (./aimo_agent.sh start) keeps the outbound channel open so AIMO can push Operations jobs. If the connection drops, the agent reconnects with backoff; results produced while offline are queued and retried until delivered.
  5. Analyze, choose tables, start monitoring. You analyze the connection, switch on the tables you want, and confirm. AIMO assigns the monitors; see Monitors.

After that, the pipeline steps that do not touch your database run on AIMO workers in the cloud: the time binding, the monitor generation, the detector's pass over the monitor history, the episode check, the table health and the briefing, all from the aggregates and artifacts the agent returned, never raw row exports. The agent keeps doing only the database-facing work: it queries your database for profiling, monitor calculation and validation, then sends the results back. See Security for the trust boundaries.

See the product site for pricing and positioning.