# pantograph

## What this is and isn't

- `libpanto/` is a pure agent SDK in Zig. Its bindings are idiomatic libraries in their language, not thin FFI wrappers.
- `panto` (CLI, `src/`) is an interactive agent SDK in the spirit of pi (https://pi.dev), not a full-featured agent. Its job isn't to do everything; it's to make everything possible — users build their own ideal agent on the Lua extensions API. Sparse built-ins are by design. Judge a feature first as "should the extension API make this buildable?", only then "core?"
- panto is not a coding tool: even the shipped coding tools (`agent/tools/*.lua`) are deny-able Lua extensions, and an extended panto should handle jobs that aren't coding at all. Coding-flavored features go out-of-tree (`../panto-agent`, the `agent.*` batteries rock), never in core.
- Server mode (near-term) is the same extension surface as a daemon proxying real inference — one proxy for all subscriptions, value-add Lua behaviors (custom routing, injected skills) server-side — not a separate product.
- New extension/API surfaces are co-designed with Travis before building, never shipped speculatively.

## Conventions

Acronyms in CamelCase are fully capitalized: `APIStyle`, `HTTPClient`, `IDLookup`. Field names are snake_case: `api_style`, `base_url`, `model`.

DO NOT read `mise.local.toml`, that contains API keys which we don't want exposed to LLM providers.