> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ntropii.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How Ntropii works

> The compiled-agent model: write (or generated) deterministic workflows in code complete with the scaffolding for humans review, deployed code executes without LLM involvement.

Ntropii is built around a counter-intuitive idea: **LLMs should generate workflow code, not be the workflow code.**

Most "AI agent" platforms wire an LLM into the execution loop — every customer interaction, every document processed, every journal entry posted runs through a model that reasons, decides, and acts. That's expensive, non-reproducible, and a regulator's nightmare in a fund-ops context where a single bad NAV calculation is a significant regulatory risk.

<Steps>
  <Step title="Design the workflow">
    A coding agent (Claude Code, Cursor, Copilot Studio) talks to Ntropii over MCP, reads your data platform schema, and **generates a deterministic Python workflow** that automates the operation. You and your team review the generated code in a normal pull request.
  </Step>

  <Step title="Test workflow locally">
    A fund accountant or operations engineer corrects anything the model got wrong — a misclassified GL account, a wrong date format, a missing edge case. Once approved, the code merges and ships.
  </Step>

  <Step title="Deploy & execute">
    The merged Python deploys to an Ntropii worker that runs *only that code* — with an LLM observer in the loop. Every NAV calculation, every journal posting, every document classification is reproducible from the workflow source plus its inputs. An auditor can replay a run from six months ago and get bit-identical output.
  </Step>

  <Step title="Observe">
    A separate observer process watches running workflows for anomalies (extraction confidence drops, reconciliation breaks, schedule slips). When something looks off, it routes the case back to a human reviewer — and only then does an LLM re-engage to suggest a fix.
  </Step>
</Steps>

## Why this matters for fund operations

Private markets fund admin runs under JFSC, CSSF, FSRA, FCA, SEC, and Big-4 audit pressure. The deployed system has to be:

* **Reproducible.** Same inputs produce the same outputs, every time, regardless of model version.
* **Auditable.** Every output traces to a specific commit of source code and a specific set of input documents.
* **Explainable.** The accountant signing a NAV must be able to defend every line of the trial balance.
* **Cheap to run at scale.** Closing 200 SPVs at month-end can't cost 200 × £40 in LLM tokens.

A workflow generated once and deployed satisfies all four. A workflow that re-reasons on every execution satisfies none.

## What you write vs what Ntropii writes

| You write                                                                                                                     | Ntropii (or a coding agent using Ntropii) writes                                                               |
| ----------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| The skill definition — a prompt that teaches the LLM what to generate for a given domain (NAV, capital call, document ingest) | The runbook itself — a Python file using the `ntro` SDK                                                        |
| Capability implementations specific to your tenant (custom GL classifier, jurisdiction-specific tax logic)                    | The orchestration: how to fetch documents, when to extract, how to call your custom logic, when to ask a human |
| Reviews and corrections in the PR                                                                                             | The correction corpus that improves the next generation                                                        |

## What you build on

The platform you reach via the CLI, MCP, and SDK has two halves:

* **Ntropii Workspace** — the control plane that holds tenants, entities, runbook registrations, workflow bindings, agent references, schedules, and notifications. Stateless about your financial data; this is where you create tenants, deploy runbooks, register external agents, and trigger runs.
* **Ntropii Tenant** — the runtime that lives inside *your* infrastructure (or ours, if you choose hosted), holds *your* credentials, and executes runbooks against *your* data platform. No customer financial data ever flows through Workspace.

A **workflow** is a binding of a **runbook** (the deterministic Python templates that drive the process) to an **entity**, optionally on a schedule. A runbook may invoke external **agents** (Claude Managed, Copilot, …) from inside its steps when it needs LLM-driven artefact generation that doesn't fit the deterministic capabilities surface.

The next page walks through this split in detail.

<CardGroup cols={2}>
  <Card title="Tenant architecture" icon="diagram-project" href="/get-started/tenant-architecture">
    The Workspace ↔ Tenant boundary and what lives where.
  </Card>

  <Card title="Data lifecycle" icon="layer-group" href="/get-started/tenant-architecture#data-lifecycle-from-agent-input-to-gl">
    The four stages from fuzzy agent input to immutable GL journal.
  </Card>

  <Card title="Configure environment" icon="gear" href="/get-started/configure-environment">
    Bind a data platform and set up your runbook repo.
  </Card>

  <Card title="Building workflows" icon="diagram-project" href="/workflows/get-started">
    Pick a template runbook or build from scratch; register external agents to drive specific steps.
  </Card>
</CardGroup>