i — Pantheon
What is Pantheon?
Pantheon is a data layer for agents: it aggregates the data scattered across your systems into one secure, governed layer, and gives you a place to define, run, and manage the work that agents do against it - scripted tasks and AI agents in the same job, on a schedule or on demand. An agent may do the thinking, but the engine decides what your role lets it reach, checks what it produces, and keeps the record of what happened.
capabilities
Cron jobs, actions, workflows, and plain-English questions.
cron jobs
It runs on a schedule.
Work that repeats at a set time — nightly reconciliations, hourly checks, a report ready every morning.
trigger cron · 0 2 * * * nightly reconciliation
trigger cron · 0 6 * * 1 weekly exceptions pack
actions
It runs once.
A single operation started by a person or another system — a button in an internal tool, or a webhook call. It runs, is recorded, and is done.
trigger manual · press the button labeled 'month-end pack'
trigger webhook · called by the ticketing system
workflows
It runs a multi-step process.
Several steps across different systems — scripts where the path is fixed, AI agents where judgment is needed, and a person approving where you require it.
agent gathers → render task → approval gate → filed
every seam schema-checked · every step on the record
chat
It answers questions about your data.
Ask a question in plain English and get an answer drawn from your data — limited to what you are allowed to see, with the sources recorded.
“which suppliers slipped last quarter?”
answer drawn from the layer · scoped to your role
Four kinds of work, one governed layer beneath them. The permissions, the checks, and the record are the same regardless of the kind of work or how it was started.
what it does
- Reaches the places your information already lives — databases, file storage, internal sites, cloud tools — and works across all of them in one job.
- Starts on a schedule, on a call from another system, or when a person presses a button or asks in plain words.
- Uses an AI agent where judgment is needed and an ordinary script where it is not — in the same process.
- Hands each step only the data the person who asked is cleared to see.
- Checks every result against the shape it was promised, and keeps a record of every call, decision, and retry.
- Keeps the processes themselves under management: versioned, watched, and held for sign-off where you say so.
what it is not
- A chatbot, or an assistant in your editor. Most of what it does, nobody watches.
- A tool for one kind of task. Reports are the easiest thing to show on a page, not the boundary.
- A model of ours. Bring the one you prefer — it runs as one step inside the job.
- A place your data moves to. Run it in our cloud, in your own account, or fully offline.
the range
What it can automate.
Eight ordinary jobs from eight parts of a company — to the engine, all the same shape: a task, a permission, a check, a record.
Most of them were automatable all along; they were not worth automating, because wiring one job safely across four systems cost more than doing it by hand. Pantheon pays for the wiring once, in the engine, and every job after the first inherits it.
- reportingThe monthly performance pack — numbers gathered from wherever they live, made sense of, and handed back finished in minutes.
- engineeringRocket test diagnostics — telemetry read against the test log, anomalies called out, checked against the standard the program is held to.
- financeLedger reconciliation — the ledger against the receipts against an outside rate feed, with the entries that do not tie out listed.
- clinicalCohort summaries — records and scans drawn together, scoped to the clinician who asked and nobody else.
- itStanding up a new network segment — addresses assigned, rules written, the change gated on a human, the whole sequence recorded.
- operationsNightly data hygiene — duplicates merged, gaps flagged, the owner of each gap told about it.
- back officeInvoices matched against purchase orders, the ones that do not match handed to a person with the reason attached.
- facilitiesTurning the office lights on. A schedule and one HTTP call — the same shape of job as all of the above, and worth saying out loud.
The engine cannot tell a rocket from a light switch. The work your company does is written down as definitions, not built into the machinery — which is what makes the range honest rather than a boast.
one run, start to finish
How a run works.
Followed here with a request for a report, because its result is the one you can see on a page. On the left, what happens; on the right, the system saying the same thing in its own words.
i
Something asks for the work.
A person presses a button or types what they want, a schedule comes round, or another system calls in. However it arrives, the request carries a name — because everything that happens next depends on who is asking.
the request, as it arriveswebhook report.request
prompt: “reconcile the Q2 ledger against the receipts and flag anything that does not tie out”
requester: u_ellis
ii
The job was written down before it ran.
Which steps run, what each may touch, and the shape the answer must take are declared in plain files — reviewed like any other change, and checked for mistakes when registered, not at three in the morning.
one of the definitions, in fulltasks/compose_report.yamlkind: taskname: compose_report@1runner: agentuses: [ledger.query, receipts.get, fx.request]output: report.spec@1ptn plan 3 tasks, 4 edges, no contract mismatches
ptn apply registered
iii
The agent never holds the keys.
Every request for data leaves through a proxy that holds the credentials. The agent receives rows and files; it never receives a password, and it cannot ask for anything the person who asked could not.
what the proxy allowed, and what it refusedpostgres.query ledger_entries · row filter: entity = ‘north’ · 1,284 rows
s3.get receipts/2026-q2/ · key prefix in scope
s3.get receipts/2026-q1/ denied for u_ellis · decision written to the log
http.request fx-rates · url allowlist checked
iv
The answer is checked before anyone reads it.
What the agent produces has to match the shape declared for it in advance. If it does not, the mistake goes back to the model to correct — twice at most — and then the run stops and says so.
the seam between one step and the nextreport.spec@1 invalid: missing field ‘findings[2].source’ · diff returned, attempt 1 of 2
report.spec@1 valid · sealed into its envelope
handed to the next step with the run, the task, the attempt, and what it cost attached
v
Something real comes out the other end.
A last step — ordinary code, no model involved — turns the result into the thing you actually wanted. Here, a finished report; on another job, a provisioned network, a filed record, or a light that is now on.
reports/q2-ledger-reconciliation.htmlwhat lands at the end of the runQ2 Ledger Reconciliation
postgres · object store · http
entries in scope
1,284
unmatched
17
variance by week
Every line on the right came from the same place: a single append-only log of everything the run did. That log is the status page, the audit trail, and the reason a half-finished run can be picked back up. Read the log →
one of them, all the way through
A report, from request to delivery.
Someone asks in plain words; the run gathers what that person is permitted to see across three systems, and hands back finished documents.
Reconcile the Q2 ledger against the receipts and flag anything that does not tie out.
…
Q2 Ledger Reconciliation
postgres · object store · http
entries in scope
1,284
unmatched
17
variance by week
ACC-4402 wire $18,400 matched
ACC-4419 card $2,187 matched
ACC-4460 wire $9,050 open
A ledger, a pile of scanned receipts, and an external rate API reconciled in one run.
Ascent Telemetry, Test 41
object store · postgres
telemetry rows
48,210
anomalies
3
chamber pressure, T+0 to T+24s
T+04.2s chamber pressure nominal
T+11.8s gimbal deflection anomaly
T+19.0s stage separation nominal
Tens of thousands of telemetry rows moved by handle, never inline, and read against the test log.
Cohort Summary, Ward 3
postgres · object store
patients in scope
36
scans rendered
12
cohort by age band
PT-0291 intake 04-11 2 scans
PT-0304 intake 04-14 1 scan
PT-0318 intake 04-19 3 scans
Patient records and the scans themselves, scoped to whoever asked - two people get two different reports.
Each report is one self-contained page with its data snapshot baked in, so it opens anywhere with nothing running behind it. The prose comes from an agent; the presentation comes from a template polished once, not a model improvising markup on the morning of the meeting.