Adapters

An adapter teaches ponens emit to read a specific coding agent's session transcript and turn it into a reasoning trace. The trace model is agent-agnostic — the adapter is the thin layer that maps one agent's transcript (its messages, tool calls, and results) onto ponens's canonical actions and lineage. Pick one with --from; the rest of the workflow (curate, declare, grade, govern) is identical no matter which agent produced the work.

Available adapters

Codex and Gemini drive much of their work through the shell, so those adapters classify shell commands into canonical actions (a sed -n/cat reads, an rg searches, apply_patch edits/creates, pytest runs tests) instead of collapsing the session to opaque commands.

ponens emit -o trace.json                            # newest session for this project (Claude Code)
ponens emit -o trace.json --from cursor              # a Cursor IDE session
ponens emit -o trace.json --from codex               # a Codex CLI session
ponens emit -o trace.json --from gemini              # a Gemini CLI session
ponens emit -o trace.json --from pi                  # a pi / CodeLogician session
ponens emit transcript.jsonl -o trace.json --from claude-code   # an explicit transcript file

Auto-detection

With no transcript path and no --from, emit finds the newest Claude Code session for the current project automatically — the common case is simply ponens emit -o trace.json right after a session. Each adapter knows its own storage convention, so pass --from to auto-detect a different agent's latest session, or give an explicit transcript path to pin one.

From your observability stack

If your agent already exports traces to an observability backend, ponens can import those instead of a raw transcript — OpenTelemetry spans and Langfuse observations become actions + lineage (these are dedicated bridges, not --from adapters):

ponens otel import spans.json -o trace.json          # OpenTelemetry spans
ponens langfuse import trace.json -o trace.json      # Langfuse observations

See Import from your observability stack for the full walkthrough.

Write your own adapter

Adapters are small, self-contained Python modules — a new agent (Windsurf, an in-house harness, …) is a single file. Each module in cli/ponens/adapters/ exposes:

NAME = "windsurf"               # the --from identifier
IMPLEMENTED = True              # flip on when it works

def default_transcript():      # newest session for this project, or None
    ...
def read_entries(path):        # transcript file -> list of raw records
    ...
def parse(entries):            # raw records -> normalized events + model/assistant metadata
    return {"events": [...], "model": ..., "assistant": ..., "last_reasoning": ...}

Register it in cli/ponens/adapters/__init__.py and it becomes a --from choice. The claude-code and pi adapters are the reference implementations to copy from; the trace builder that turns normalized events into a trace is shared, so an adapter only has to speak its agent's transcript format.