The anatomy of Frontier.
One ledger at the centre. An agent runtime on top of it. Connectors feeding it, a governance shell around it, and the same primitives your engineers build on. Here is every part, and what each one guarantees.
Five subsystems. One book of record.
Nothing in Frontier floats. Every capability on this page belongs to one of these five, and all five write through the same ledger.
Every transaction, once, in one place — with the history of how it got there.
Ledger Agents that read the core, do the tedious part, and hand you the judgment call.
Banks, billing, payroll and warehouse — typed on the way in, reconciled on arrival.
Policy, permissions and an audit trail wrapped around every write, human or agent.
SDK, API and MCP — the exact primitives Frontier’s own agents call.
One book. Always current.
Frontier’s core is a double-entry ledger that records events, not screenshots. Every invoice, payment, payroll run and journal lands as an immutable event with its source attached — so the balance you open at 09:00 is the balance, not last night’s extract.
| Property | Guarantee |
|---|---|
| Model | Double-entry, event-sourced, append-only |
| Consistency | Serializable writes; one writer per entity |
| Multi-entity | 240 entities, 31 currencies, one consolidation |
| Periods | Soft-close by day, hard-close by period, reopenable with trail |
| Restatement | Corrections post forward — history is never edited |
| Latency | 38 ms p99 write · 120 ms p99 consolidated read |
Agents that work the ledger, not around it.
Ledger Agents run on the core’s live state under the same permissions model your people have. They match, code, accrue, chase and escalate — continuously, with their reasoning on the record. Nothing runs off a copy. Nothing posts without a trail.
| Capability | Behaviour |
|---|---|
| Runtime | Continuous — event-triggered and scheduled |
| Grounding | Reads live ledger state; no exports, no stale extracts |
| Authority | Scoped per agent by entity, account and threshold |
| Escalation | Anything outside policy stops and asks, with its evidence |
| Reasoning | Every step logged, replayable, attributable |
| Throughput | 2.6M actions/month across 74k live agents |
Everything that touches money, wired in.
Connectors are typed in both directions. Data arrives mapped to the ledger’s schema, reconciled against what is already there, and flagged where it disagrees — so an integration is a source of truth, not another place to check.
| Property | Guarantee |
|---|---|
| Direction | Bidirectional — read, write and write-back |
| Mapping | Typed to the ledger schema at the boundary |
| Reconciliation | Every inbound record matched on arrival, not at close |
| Backfill | Full history on connect, incremental after |
| Failure | Idempotent retries; gaps are surfaced, never silent |
| Custom | Any HTTP source via the connector SDK |
Every write passes through the same gate.
Policy is not a review step at the end. Permissions, thresholds and approval routes sit between every actor and the ledger — the same gate for a controller, a contractor and an agent. What passes is recorded. What does not, stops with a reason.
| Control | Enforcement |
|---|---|
| Permissions | Entity, role and account scoped — inherited, never ad hoc |
| Policy | Thresholds and rules evaluated pre-post, on every line |
| Approvals | Routed by amount, entity and cost centre; SoD enforced |
| Audit trail | Actor, action, before, after, timestamp — immutable |
| Agent parity | Agents obey the identical policy set as people |
| Attestation | SOC 2 Type II · ISO 27001 · exportable evidence pack |
| Actor | Action | Written |
|---|---|---|
| agent · reconcile-1010 | matched 1,284 lines | 08-14 02:11:06 |
| agent · accrual-draft | drafted je_8f21c4 | 08-14 02:11:44 |
| policy · threshold >$5k | held for CFO approval | 08-14 02:11:44 |
| m.shen · controller | approved je_8f21c4 | 08-14 09:02:18 |
| system · period 2026-08 | soft-closed | 08-15 00:00:02 |
The same primitives, exposed.
No private path.
Frontier’s own agents post journals, run reconciliations and read balances through the public interface. Whatever we build on the platform, you can build too — typed, versioned and rate-limited the same way.
| Surface | Shape |
|---|---|
| SDK | TypeScript and Python, generated from the API spec |
| API | REST + JSON, typed and versioned — 399M calls/week |
| MCP | Every ledger primitive as a tool your agents can call |
| Webhooks | Signed, ordered, at-least-once, with replay |
| Sandbox | A full ledger with seeded data — free, no expiry |
| Limits | 1,000 req/s burst · idempotent writes · 99.99% SLA |
The whole platform, on one sheet.
All 30 capabilities, filed under the subsystem that owns them.
| Capability | Notes |
|---|---|
| General ledger | Journals, accounts, dimensions, custom attributes |
| Multi-entity consolidation | Intercompany elimination, ownership tiers |
| Period close | Checklist, soft-close, hard lock, reopen with trail |
| Capability | Notes |
|---|---|
| Reconciliation agents | Bank, card, intercompany and sub-ledger tie-outs |
| Coding and accrual agents | Account, entity and cost-centre coding from history |
| Ask Frontier | Plain-language query over the live ledger, with sources |
| Capability | Notes |
|---|---|
| Banks and card networks | Direct feeds and aggregators, statement-level detail |
| Billing and revenue | Stripe, Shopify and invoicing, matched to contracts |
| Payroll and HRIS | Runs, accruals and headcount, mapped to cost centres |
| Capability | Notes |
|---|---|
| Policy engine | Thresholds, required fields, vendor and duplicate checks |
| Approval routing | By amount, entity, cost centre and vendor risk |
| Audit trail | Immutable, queryable, exportable, agent-attributed |
| Capability | Notes |
|---|---|
| REST API | Every object, typed and versioned, with cursors |
| SDKs | TypeScript and Python, generated, semver-tracked |
| MCP server | Ledger primitives as tools for your own agents |
Five parts. One guarantee.
Every number on this page comes out of the same ledger, checked by the same policy set, reachable through the same API. That is the whole design — and it is why the answer you get at 09:00 is one you can defend at 09:05.
