---
url: https://pencel.ai/docs/concepts/compiler-runtime.md
description: >-
  How Pencel's agentic compiler turns a plain-language workflow into a safe,
  runnable plan — and how the runtime executes it as a briefing with
  system-enforced guardrails and a post-run check.
---

# Agentic compiler & runtime

When you [Build](/concepts/chat) a [Workflow](/concepts/playbooks), Pencel doesn't just hand your description to a model and hope for the best. It runs a small pipeline that keeps three jobs separate — **planning**, **compiling**, and **running** — so the result is predictable and safe to run unattended.

This page explains what happens at each stage and why it's designed this way. You never need to think about any of it to use Pencel; it's here for the curious.

## The three stages

```
Plan (with a model)  →  Compile (no model)  →  Run (agentic, guarded)
```

| Stage | Uses a model? | Produces |
|-------|:-------------:|----------|
| **Plan** | Yes | A *semantic plan* — the intended outcome, shape of the work, and success criteria |
| **Compile** | No | A concrete *physical plan* — tools bound, inputs filled, guardrails set |
| **Run** | Yes (the agent) | The actual work, plus a record of what happened |

### 1. Plan — with a model

You describe the outcome in plain language. A model proposes a **semantic plan**: what the workflow is for, roughly what steps it involves, which capabilities it needs, and what "done" looks like. This is the *only* place AI shapes the workflow. If the plan is missing something it can't infer, Pencel asks you a clarifying question instead of guessing.

### 2. Compile — with no model

Pencel then **compiles** that plan into a **physical plan** — deterministically, with no model calls. Compilation is where intent becomes something executable and testable:

* **Binds each step to a real tool** — a specific built-in or a live [connection/MCP](/concepts/connections) tool, not a vague instruction.
* **Fills in inputs and expands templates** — placeholders like the run date or your email address are resolved to concrete values.
* **Marks what needs approval** — anything that sends or changes data is flagged for a gate.
* **Checks a large set of invariants** — consistency and safety rules the plan must satisfy.

Compilation ends in one of three states:

* **Compiled** — ready to run.
* **Needs input** — an open question is blocking; Pencel asks you.
* **Blocked** — it can't be made safe or complete, so Pencel refuses rather than shipping something broken.

Because compilation is deterministic and model-free, the same plan compiles to the same result every time — which is what makes a workflow *repeatable* rather than a fresh improvisation on each run.

::: info Not everything compiles to fixed steps
Pencel compiles the workflow shapes it understands well today (a record-processing pipeline, and a single-call delivery). For anything else — or when a compile can't cleanly succeed — it falls back to a plain-language **briefing**, so a workflow is never worse off than an un-compiled one.
:::

### 3. Run — agentic, with guardrails

At run time the compiled plan is rendered into a **briefing** — a clear set of instructions the agent reads as its starting context. The agent then does the work in a single guided pass, calling tools as needed.

The key design choice: the briefing is a **strong suggestion, not a rigid program**. The agent can adapt to what it actually finds — but the limits that matter are enforced by the *system*, not left to the model's discretion:

* **Forbidden actions are blocked outright.** Tools the plan didn't authorize simply aren't available.
* **Send/change actions pause for approval.** Based on your [guidelines](/privacy-and-security/approval-workflows), the agent stops and asks before anything leaves your machine or changes data.
* **Cost and iteration ceilings** stop a run from spiraling, scaled to the size of the plan.
* **Time is re-grounded at the moment the run starts**, so "this week" means the right week even for a schedule set up months ago.

## Runs use a frozen snapshot

A run executes the **snapshot** of the plan captured when it started — not the live workflow. Editing a workflow never changes a run already in flight, and you can always see exactly what a past run was told to do. This is why re-running last month's report reproduces last month's behavior.

## Checked after the fact

When the run finishes, Pencel doesn't just take the agent's word for it:

* **Conformance check** — it compares what the agent actually did against the compiled plan.
* **Success-criteria verdict** — it evaluates the final output against the "done" definition from the plan and records the verdict on the run.

Together these give you a run you can trust and inspect, rather than an opaque black box.

## Why solution packs feel instant

[Marketplace](/concepts/solutions) packs ship workflows that carry a plan with them, so Pencel **compiles them at install** — you get a bound, approved plan instead of a blank template. If your connections aren't live yet at install time, the pack keeps a plain-language version and **re-compiles on first run** once the real tools are available. Either way, a pack is never worse than an un-seeded template.

## Why it's built this way

* **Predictable** — deterministic compilation means the same workflow behaves the same way each run.
* **Safe to automate** — guardrails are enforced by the system, so unattended runs can't quietly overstep.
* **Inspectable** — snapshots, conformance, and a success verdict make every run auditable.
* **Adaptable** — the agent still reacts to reality at run time instead of breaking on the first surprise.

## What's next

* [Workflows](/concepts/playbooks) — what the compiler produces
* [Run mode](/concepts/chat) — the live counterpart to a built, compiled workflow
* [Approval workflows](/privacy-and-security/approval-workflows) — the gates enforced at run time
* [Under the Hood](/concepts/under-the-hood) — dynamic UI and knowledge-graph construction