# Architecture

# Architecture

inline is deliberately one deployable thing. There's no separate queue service and no microservice mesh — a single application does the GitHub event handling, the background work, the portal, and the MCP server, powered by Claude and backed by your own cloud tenancy.

## The pieces

```text
                       ┌──────────────────────────────────────────┐
   GitHub  ──events──► │  inline                                  │
   Portal  ──HTTP────► │                                          │
   Coding  ──MCP─────► │   • GitHub App (events + bot identity)   │
   agents              │   • admin portal                         │
                       │   • always-on background reviewer        │
                       │   • MCP server (pre-PR review)           │
                       └──────────┬─────────────────┬─────────────┘
                                  │                 │
                          your cloud database    Claude
                          + artifact storage     (fast / balanced / deep tiers)
                                  │
                          isolated sandboxes
                          (code-graph, tests, fixes)
```

## How the work flows

The split that makes inline cheap and reliable: **receiving an event does almost nothing, and the background reviewer does the work.**

- **Events arrive and are recorded.** When GitHub sends a pull-request event (or you act in the portal), inline verifies it and records the work to be done. This returns immediately — no model work happens on the request path.
- **The background reviewer runs continuously.** An always-on worker picks up recorded work, claims each item, serializes work per-PR so two reviews of the same PR never collide, and runs the right task — a review, an `@inline` command, a feedback harvest, a merge-gate recompute, a sandbox test, a fix, an index build, a CI run, or a pentest. Results post back to GitHub and stream live to the portal.

## The model tiers

inline uses Claude across three tiers, chosen per task by cost and difficulty — this tiering is the core cost lever:

| Tier | Used for |
| --- | --- |
| **Fast** | Triage, code explorers, repo memory, walkthroughs, first-pass assessment. |
| **Balanced** | Chat, deep security and compliance assessment, cloud analysis, CI triage. |
| **Deep** | PR deep review, test authoring, fix generation, pentest validation. |

Every call's cost is recorded from live token usage, so you always know what a review cost. See [cost & two-tier models](./review-cost.html).

## State & storage

- **Your database** holds everything relational — organizations, connections, repos, reviews, findings, and settings. It lives in your own cloud tenancy.
- **Artifact storage** holds large objects — code-graph indexes, sandbox videos and screenshots, compliance documents.
- **Isolated sandboxes** are ephemeral environments for anything that needs to run code: code-graph builds, [sandbox tests](./sandbox.html), and [fix](./auto-fix.html) verification.

## Live updates

The portal gets real-time progress over a live event stream, scoped per organization. Index builds, security fixes, compliance analysis, and cloud scans all stream their phase transitions to the UI.

## Integrations

- **GitHub** — via a multi-tenant GitHub App or per-admin OAuth ([connect](./connect-github.html)).
- **Microsoft Teams** — Adaptive Card alerts via Power Automate webhooks ([notifications](./notifications.html)).
- **MCP** — an authenticated Model Context Protocol server for [pre-PR review](./mcp.html) inside coding agents.
- **Web search** — optional search/fetch for reviews, threat news, and compliance research.

Read on: **[the review pipeline](./review-pipeline.html)** for what happens on every PR, and **[security & trust](./security-trust.html)** for how your code and credentials are handled.