ore

ore are the inputs to an agentic system.

ore is a Go-native framework for building agentic applications. It provides a minimal core inference primitive, provider-agnostic LLM adapters, composable I/O conduits, and clean extension points implemented as Go interfaces.

This is a learning project and a conceptual exploration. It is inspired by pi.dev's philosophy of minimal cores and aggressive extensibility, but reimagined in Go with different architectural priorities: first-class non-interactive conduits, build-time composition via Go interfaces, and a narrower core that delegates all workflow opinions to extensions and applications.

1. Simplicity — The core does as little as possible. Every feature that can live outside the core does.
2. Composability — Components connect through narrow interfaces. A Step, an OpenAI adapter, a tool handler, and a TUI conduit compose the same way as a Step, an Anthropic adapter, an image handler, and a webhook conduit.
3. I/O Agnosticism — The core does not know whether it is running in an interactive terminal or responding to a 3 AM PagerDuty alert.
4. Build-time Extension — Extensions are Go packages composed at build time, not runtime plugins. This keeps deployment simple and interfaces type-safe.
5. Defer Specifics — Patterns like memory, reflection, planning, reasoning strategies, multi-agent orchestration, and tool calling emerge as artifact handlers and orchestrators, not as core implementations.
6. Treat Tool Calling as an Extension — Tool calling is one artifact handler among many. This ensures the architecture can absorb future LLM capabilities without core changes.

[ore] is conceptually descended from pi.dev, a mature TypeScript terminal coding harness. Where ore diverges: Language (Go instead of TypeScript), I/O Conduits (all ingress/egress adapters are first-class, not just TUI), Extension Model (Go interfaces and build-time composition instead of runtime module loading), and Scope (a framework for building agents, not a specific agent implementation).

Extensions (provider adapters, conduits, and tool implementations) live under x/.

The fastest way to understand ore is to run one of the hand-written examples. Each is a complete, compilable Go program that wires the framework together without any YAML or code generation layer.

• examples/http-chat/ — Stateful HTTP chat server with NDJSON streaming, SSE events, and an optional web UI.
• examples/tui-chat/ — Interactive terminal chat with Markdown rendering and persistent thread store.
• examples/calculator/ — Single-turn CLI demo with tool calling (add, multiply) via the ReAct cognitive pattern.
• examples/filesystem/ — File system tool demo with path resolution and working directory constraints.
• examples/single-turn-cli/ — Minimal single-turn CLI example with direct provider invocation.

For a more fully fledged coding agent built on ore, see andrewhowdencom/workshop.

Note: The TUI conduit's conversation view is cached locally. If your application replaces thread state via stream.LoadTurns (e.g. after compaction), call tui.ReloadHistory(stream.Turns()) to refresh the UI. See x/conduit/tui/README.md for details.

All examples read ORE_API_KEY from the environment. Set ORE_MODEL to choose a different model (default: gpt-4o). Set STORE_DIR for persistent JSON thread storage.

See Development / Validation for how to validate the entire codebase before submitting changes.

The repository uses Taskfile for common developer commands. The root task validate runs the full lint–test–build pipeline for all 16 workspace modules (root, examples/, and every x/* package):

task validate

Validate a single module only (e.g. the TUI conduit):

task x-conduit-tui:validate

Running task validate from the repo root therefore guarantees that the entire codebase stays healthy.