Prose · Agentic Engineering Lisbon

PROSE01 / 12

OpenProse

A new kind of language for a new kind of computer.

Speaker

Luis Freitas

Role

Co-founder, Frames.AG

Handle

@microchipgnu

Venue

Agentic Engineering Lisbon @ The Nest

Date

2026-05-27

§ 01 · OpeningLisbon · 2026-05-27

PROSE02 / 12

Thesis

Turn recurring prompts
into reusable workflows
that run on your harness.

Format

Markdown

Runtime

your harness, unchanged

Input

prompts you already write

Output

composable, re-runnable workflows

The substrate

LLM OS diagram (Karpathy, 2023) — Karpathy · 2023 · "an LLM is a new kind of computer"

Subagents, filesystem, tools, persistence · the OS that finally shipped. You're already on the computer.

1 · Karpathy proposed this. In 2023, Andrej Karpathy made a claim: an LLM isn't a chatbot — it's a new kind of computer. Model is CPU. Context is RAM. Filesystem is disk. Tools are syscalls.

At the time that was a thought experiment. The pieces had names. But you couldn't actually run anything on this computer — there was no runtime.

[Advance the substrate panel · harness list appears.]

2 · The harnesses shipped it. Over the past two years, the labs and the open-source community shipped that computer. Claude Code · Codex · OpenCode · Pi · Gemini CLI — and a dozen others. You use one of these every day.

So the OS Karpathy described has a real address now.

3 · Which connects back to the thesis on the left. "Turn recurring prompts into reusable workflows that run on your harness."

Your harness is that computer. The recurring prompts are the pain we just talked about. The only missing piece is the format that turns them into workflows. That's what the rest of this talk is about. ⏸

§ 02 · ThesisOne-line pitch

PROSE03 / 12

Mental model

What sits between a prompt and a program?

program (n.)

a sequence of instructions written in a programming language that tells a computer exactly how to perform a specific task.

Conventions

AGENTS.md

text the agent reads

Context

CLAUDE.md

text Claude remembers

Capability

SKILL.md

text the agent loads

Program
.prose.md
text the runtime can execute

AGENTS, CLAUDE, SKILL scaffold the agent.
Prose gives shape to instructions that run as programs.

What sits between a prompt and a program?

Worth grounding the word: a program is a repeatable artifact written for a runtime. It takes inputs, follows some contract, and produces outputs.

Now look at the agent stack.

AGENTS.md gives repo-wide conventions.

CLAUDE.md gives Claude project context.

SKILL.md gives the agent reusable capabilities it can load on demand.

These are good. Keep using them.

But they are not quite the missing layer.

You don't re-run a CLAUDE.md like a script.

You don't usually compose an AGENTS.md into another workflow.

And a SKILL.md is more like a capability than an application.

The missing layer is where agent work becomes a stable executable unit:

· declared inputs
· declared outputs
· reusable workflows
· composable services
· auditable traces

AGENTS, CLAUDE, SKILL scaffold the agent.

Prose gives shape to instructions that run as programs. ⏸

§ 03 · Mental modelSticky notes vs scripts

PROSE04 / 12

Shape

Contract Markdown.

---
name: security_review
kind: service
---

### Requires
- diff: the code diff to review

### Ensures
- findings: list of security concerns with file:line refs
- severity: low | medium | high

No hardcoded chain · no brittle mega-prompt · no hand-drawn DAG. The contract is the interface. The runtime decides the execution plan.

Anatomy

Kind

service

Name

security_review

Inputs

diff

Outputs

findings, severity

Authoring

Contract Markdown is the default. A small scripting mode exists for explicit order, retries, or loops — most workflows don't need it.

§ 04 · ShapeContract Markdown

PROSE05 / 12

What you just saw

That was a service.
Other kinds compose from there.

service
one unit of agent work
"review this diff for security issues"

system
a composition of services
"fetch the diff, run three reviews, post a comment"

responsibility

a standing goal that wakes itself up

"every PR gets reviewed within 5 minutes"

…and more

other kinds for specific cases

see github.com/openprose/prose

Same Markdown format for all of them. The kind: field at the top tells the runtime which one it is. Today we'll focus on service and system.

§ 05 · Building blocksservice · system · and more

PROSE06 / 12

Worked example · a system

Six services that review a PR.

---
name: pr-review
kind: system
---

### Requires
- pr_event

### Ensures
- posted_comment_url

### Services
- fetch_diff
- security_review · performance_review · docs_review
- synthesize · post_comment

Six services · flat list · no edges, no order declared anywhere.

Anatomy

Kind

system

Name

pr-review

Input

pr_event

Output

posted_comment_url

Services

6

Open question

No order declared anywhere. So how does the runtime know what runs first?

§ 06 · Worked exampleOne system · no order declared

PROSE07 / 12

How does it know
what runs first?

Forme · the wiring layer

It reads outputs against inputs. No graph to draw.

Result

DAG falls out

Parallel

3 reviewers

Cost

zero wiring

You didn't draw the DAG. Flat list + tight contracts. Parallelism falls out for free.

Forme · output

The DAG you saw, as JSON.

{
  "id": "pr-review", "systemName": "pr-review", "sourcePath": "src/pr-review.prose.md",
  "graph": [
    { "id": "fetch_diff",         "inputs": [{"name":"pr_event","from":"caller"}],                          "outputs": [{"name":"diff","public":true}] },
    { "id": "security_review",    "inputs": [{"name":"diff","from":"service","sourceNodeId":"fetch_diff"}], "outputs": [{"name":"findings","public":true}] },
    { "id": "performance_review", "inputs": [{"name":"diff","from":"service","sourceNodeId":"fetch_diff"}], "outputs": [{"name":"findings","public":true}] },
    { "id": "docs_review",        "inputs": [{"name":"diff","from":"service","sourceNodeId":"fetch_diff"}], "outputs": [{"name":"findings","public":true}] },
    { "id": "synthesize", "inputs": [
        {"name":"security_findings",   "from":"service","sourceNodeId":"security_review"},
        {"name":"performance_findings","from":"service","sourceNodeId":"performance_review"},
        {"name":"docs_findings",       "from":"service","sourceNodeId":"docs_review"}
      ], "outputs": [{"name":"review","public":true}] },
    { "id": "post_comment",       "inputs": [{"name":"review","from":"service","sourceNodeId":"synthesize"}], "outputs": [{"name":"comment_url","public":true}] }
  ],
  "executionOrder": [
    { "nodeId": "fetch_diff",         "dependsOn": ["caller"] },
    { "nodeId": "security_review",    "dependsOn": ["fetch_diff"] },
    { "nodeId": "performance_review", "dependsOn": ["fetch_diff"] },
    { "nodeId": "docs_review",        "dependsOn": ["fetch_diff"] },
    { "nodeId": "synthesize",         "dependsOn": ["security_review","performance_review","docs_review"] },
    { "nodeId": "post_comment",       "dependsOn": ["synthesize"] }
  ],
  "trace": { "vm_log": "vm.log.md" }
}

A Forme manifest · compiled before any service runs · the runtime walks this.

How does the runtime know what to run first? Let that hang for a beat.

[Advance · the diagram appears.]

It scans every service's outputs against every other service's inputs. fetch_diff produces diff. security_review requires diff. Match. So does performance_review. So does docs_review.

Three services all consume the same upstream, and · importantly · none of them depend on each other. Forme sees that, and runs them in parallel.

Then synthesize requires all three findings. So it waits. Then post_comment requires the synthesized review.

[Advance · edges draw.]

The DAG that fell out: fetch the diff, fan out to three reviewers in parallel, fan in to synthesize, then post.

You didn't draw it. ⏸

You wrote a flat list with tight contracts. The parallelism fell out for free.

This wiring layer is called Forme. If two services produced findings under the same name, Forme wouldn't guess — it escalates with a clear error pointing at the contracts you need to tighten. That's a feature.

[Advance · the manifest.]

This is what Forme actually produces — a JSON manifest. Same DAG, encoded for the runtime. Every node has typed inputs and outputs, every edge is named, and at the bottom you can see trace.vm_log · the receipt the VM will write when it runs this.

§ 07 · FormeThe wiring falls out · into a manifest

PROSE08 / 12

Runtime · run it live

There is no prose binary.

It's a command routed into your harness.
The skill embodies a small VM
that interprets your .prose.md.
Prose parasitizes the harness you already use.

claude code · agent session harness

$

filesystem · your repo 1 entry

src/pr-review.prose.md

Last reveal before we wrap.

You'll see things like prose compile, prose serve, prose run in the docs. They look like shell commands. They aren't.

prose run isn't like python script.py. Inside Claude Code or Codex, it's a command routed into the agent runtime.

The open-prose skill reads the file, embodies a small VM, walks the wiring Forme inferred, and writes a vm.log.md as the run's receipt.

And here's the part that matters — Prose doesn't ship a giant orchestration server. It parasitizes the harness you already use. The harness provides filesystem, subagents, tools, and model. Prose provides the program format and the execution discipline.

[Backup line if anyone asks "but how do you trigger it / run it on schedule?"] The harness is the runner. The skill is the VM. Prose is the contract for what gets run. We don't ship a new runtime — we ship the missing program format. Runners already exist; the agent-native contract didn't.

§ 08 · RuntimeThe skill is the interpreter

PROSE09 / 12

How it runs

Three layers · all already in your harness.

01

Spec

open-prose skill

a folder of Markdown · teaches the model how to read .prose.md, wire Forme, walk the plan

02

Interpreter

the model itself

loads the spec into context · walks it · constrained by the contract

03

Primitives

spawn · read · write · copy

tools the harness already provides · no new infrastructure

Specification-as-instruction. The skill is the spec. The model is the interpreter. The harness is what runs.

So how does it actually run? Three layers — and all three already exist in your harness.

Layer 1 · the spec. The open-prose skill is just a folder of Markdown files. It teaches the model how to read a .prose.md file, how to do the Forme wiring, how to walk an execution plan, how to spawn subagents, and how to write the trace. The skill is detailed enough that it acts as the runtime spec.

Layer 2 · the interpreter. The model itself. When the harness loads the skill's instructions into context, the model — following those instructions — behaves as the Prose VM. Where the model has discretion, the contracts constrain it. Where the contracts are ambiguous, Forme escalates rather than guessing.

Layer 3 · the primitives. Every operation the runtime needs — spawn a subagent, read a file, write a file, copy outputs — maps to a real harness tool that already exists. No new infrastructure.

Specification-as-instruction. Same trick as the JVM, except the interpreter is the model reading the spec, not a C++ runtime.

[If a skeptic asks "wait, the skill is just markdown?"] Yes — and that's the whole trick. The spec is detailed enough — file kinds, contract sections, Forme matching, primitive operations — that the model executes it consistently. Where the model has discretion, the contracts constrain it. Where contracts are ambiguous, Forme escalates rather than guessing. Same wager every skill makes: a sufficiently precise specification is implementation.

§ 09 · How it runsspec · interpreter · primitives

PROSE10 / 12

Production

Frames runs on Prose.

We use it every day. Every entry at frames.ag/datasets is produced by Prose programs.

Concrete example · our dataset refresh responsibility discovers candidate rows, enriches them, attaches source evidence, diffs against the previous run, and writes the trace. All Prose.

Surface

frames.ag/datasets

Curated agentic-stack datasets, refreshed continuously.

Stack

Goals

responsibilities

Workflows

systems

Work

services

§ 10 · Production

PROSE11 / 12

On-ramp

Install. Write. Replace.

01 · install

npx skills add openprose/prose

into Claude Code or Codex

02 · write

one service

the smallest unit · one .prose.md file

03 · replace

one recurring prompt

something you re-type today

openprose.ai github.com/openprose/prose

Caveats

Young

v0.14 · track HEAD

Non-deterministic

path may vary

Cost

N model calls per run

Hosted

early access · self-host for now

§ 11 · Adopt safelybounded, auditable, on-ramp

PROSE12 / 12

Thanks.

Find me

Speaker

Luis Freitas

Handle

@microchipgnu

Company

Frames

Links

Frames

frames.ag

Datasets

frames.ag/datasets

Prose

openprose.ai

Repo

github.com/openprose/prose

§ 12 · ThanksLisbon · 2026-05-27