i — the works
Some work runs itself. Some you ask for.
A company's information is scattered across dozens of places - databases, spreadsheets, mail, cloud tools, internal sites. Pantheon reaches them through the interfaces they already expose and runs work across them: jobs that go quietly on a schedule, and named processes anyone permitted can call with a button or a sentence in plain English. Anything software and data can touch is in range.
in plain terms
Define it once, run it forever, and keep it under management.
Pantheon is a workflow automation platform: a place to define, run, and manage reliable processes, built from ordinary scripted tasks and AI agents in the same job. A process is written down once and then runs, over and over, without anyone minding it. An agent may do the thinking, but the engine decides what it can reach, checks what it produces, and keeps the record of what happened.
The agent is the clerk. Pantheon is the building: the vault, the rule about which drawer that clerk may open, the ledger of the ones they did, and the night shift that runs when the clerk has gone home.
two faces, one system
Work that arrives on its own, and work you go and ask for.
asked for
Someone calls it.
A named process anyone permitted can start: a button in an internal tool, a sentence typed in plain English, or a call from another system. Nobody needs to know how any of it works.
trigger manual · press the button labelled 'month-end pack'
trigger webhook · “which suppliers slipped last quarter?”
trigger webhook · called by the ticketing system
unattended
Nobody calls it.
The same kind of job with a schedule or an event on the front of it, running while everyone is asleep — nightly reconciliations, hourly checks, packs that land before anyone has asked.
trigger cron · 0 6 * * 1 weekly exceptions pack
trigger cron · 0 2 * * * nightly reconciliation
trigger webhook · fires when a test run finishes
The same definitions with a different trigger on the front. The permissions, the checks, and the record do not change with the door a job came in through.
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 judgement 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
Anything software and data can touch, Pantheon 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 programme 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
Every job, whatever it is, runs the same five ways.
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 arrives
webhook 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 full
kind: task name: compose_report@1 runner: agent uses: [ledger.query, receipts.get, fx.request] output: report.spec@1
ptn 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 refused
postgres.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 next
report.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.
what lands at the end of the run
Q2 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
Asked for in a sentence. Finished in minutes.
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.
the full account →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.
the full account →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.
the full account →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.