Question 1

What is Obsidura?

Accepted Answer

Obsidura is the company. Pantheon is the product: a data layer for AI agents. It aggregates the systems your information is scattered across into one secure, governed layer and sets agents to work against it - recurring jobs on a schedule, one-off actions, whole workflows, or a question asked in plain English and answered from your data. Access is scoped to each person's role, and it escalates to a person where you say it must.

Question 2

What is Pantheon?

Accepted Answer

In plain terms, one governed layer over your company's data, and a place to define, run, and manage the work that agents do against it. Underneath, a workflow orchestration engine where definitions are data, not code: your YAML compiles into a typed graph held in Postgres, a Rust executor instantiates runs from it, task bodies run in containers speaking JSON-RPC over stdio, and every resource call passes through a proxy scoped to that run.

Question 3

What kinds of work can it automate?

Accepted Answer

Anything software and data can touch. A month-end performance pack, a nightly ledger reconciliation, diagnostics over rocket test telemetry checked against the standard a program is held to, a clinical cohort summary, standing up a new network segment with a human gate on the change, matching invoices against purchase orders, or turning the office lights on. To the engine these are the same shape: a task, a permission, a check, and a record.

Question 4

Does it only produce reports?

Accepted Answer

No. Reports are the example we lead with because the result is something you can see on a page, and because a report exercises the hard parts - many systems, per-person permissions, large data, a polished artifact. A job whose result is a provisioned network, a filed record, a notified person, or a switched-on light runs through exactly the same five steps.

Question 5

Does someone have to ask for every run?

Accepted Answer

No. A run starts from a schedule, from another system calling in, or from a person - a button in an internal tool or a sentence typed in plain English. The definitions are identical either way; only the trigger on the front of the job differs, so a process written to be called can be put on a schedule without rewriting it.

Question 6

Are the AI agents doing everything?

Accepted Answer

No, and that is deliberate. A task is either a traditional scripted task or an agent, and both run the same way. Agents are used where judgment is genuinely required - reading a mess of data and deciding what matters - while deterministic steps handle everything that should never vary, like composing the final artifact or writing a record. An agent is an ordinary task carrying extra policy, not a special execution path.

Question 7

How do agents access our systems?

Accepted Answer

Through a proxy. Each run gets a Unix socket mounted into its container, and that socket is the capability - the container is never handed a credential. The proxy checks the grants minted for the run, performs the call with the real credentials, writes an audit event, and returns the data.

Question 8

How are permissions scoped?

Accepted Answer

A grant maps a user to a resource, the verbs they may use, and a scope in that connector's own terms: a SQL row filter for Postgres, a key prefix for object storage, a URL allowlist for HTTP. Grants are enforced on every call, so two people can ask the same question and get answers drawn from different data.

Question 9

What happens when a step needs a person?

Accepted Answer

A task can gate on approval. The pending decision lives in Postgres, so the run suspends durably - restart the executor and it is still waiting - and continues when someone approves it.

Question 10

What stops an agent returning malformed data?

Accepted Answer

Every task output is validated against its declared schema before anything downstream sees it. When an agent produced it, a validation failure sends a truncated error diff back to the model for a bounded number of repair attempts, then fails typed into the run log rather than passing bad data along.

Question 11

Is every action logged?

Accepted Answer

Yes, and the log is not a side report. Every run is an append-only stream of events in Postgres, and executor state is a fold of that stream. Status, the audit trail, approval suspend and resume, and crash recovery all read the same table.

Question 12

Which systems can it connect to today?

Accepted Answer

Three connector kinds: Postgres, S3-compatible object storage, and HTTP. HTTP is the general case - if a system has an interface a program can call, a task can work against it through the same proxy. The v1 connector catalog - Google Workspace, Microsoft 365, Slack, Jira, Azure, NAS shares, more databases, and MCP servers - is specified and public on the connections page, and arrives in phases.

Question 13

How will we connect our own services?

Accepted Answer

Through the Connections surface: pick the service, walk its consent screen or enter a credential, and the secret goes into executor custody - never into YAML, a diff, or a container. Setting up a connection is self-serve; making it reachable from a job always goes through a reviewed resource definition. Grants are then written per user in each service's own terms - a folder prefix for Drive, a channel allowlist for Slack, a JQL fragment for Jira.

Question 14

Are you locked to one agent framework?

Accepted Answer

No, and it is an architectural rule rather than an intention. No framework is hardcoded at the executor level. The harness is a leaf dependency inside the runner image, so swapping it touches no engine code.

Question 15

Where can Pantheon run?

Accepted Answer

Three deployment options: our managed cloud, a private VPC inside your own cloud account, or on-premises on your hardware with no outbound calls. The security model is the same in all three.

Question 16

How do we get started?

Accepted Answer

Book a demo through the contact page. We map one of your workflows on a 30-minute call and show you the audit log by the end of it.

Frequently asked questions.