Platform
Developer tools
These are the tools we build and use ourselves. Grist handles document parsing, AgentCtl runs agents, and Erasmus ties models and services together in workflows you can reuse.
Grist
Grist is our document parser. It reads documents and turns them into structured data that other tools can work with. Once a document has been through Grist, the rest of your stack does not have to care where the file came from or how messy it was.
AgentCtl
AgentCtl invokes agents. It is a light, configurable wrapper around the provider of your choice, so you can point it at whichever model you want to use and swap providers later without changing how you work.
Erasmus
Erasmus is our tooling layer. It provides AI and traditional tooling in reusable workflows, so a model, some media processing, and a parser can be chained into a pipeline you build once and run as often as you need. Not every step in a workflow needs AI, and Erasmus treats both kinds of step the same way.

Where ldgr fits
These tools do the work, and ldgr records it. Tasks, runs, and decisions land in one place, so the work can be picked up in a later session or checked after the fact.
What the tools produce
One brief. One long-running agent loop. One working event platform.
Session Board began as a high-level competition brief describing the product, its primary workflows, and the result entrants should deliver — not the implementation architecture. A Pi coding agent turned it into a multi-service application without active supervision, while ldgr kept the work structured across the full build.
That structure mattered because the system did not fit in one prompt or one context window. ldgr supplied bounded work, recorded runs, evidence, validation, and decisions, so the loop could continue across a long build without treating each new session as a new project. The retained planning ledger expands the production specification into 98 dependent work items.
ldgr did not write the code. It made the long-horizon agent process coherent enough to finish the system.
The result
Session Board is an open-source event operations platform. The current demonstration uses mock data and configured third-party integrations.
Programme operations
- Create and schedule events
- Build submission and onboarding forms
- Evaluate proposals across review rounds
- Manage agendas, rooms, tracks, and conflicts
Speaker operations
- Add and onboard speakers
- Collect bios, headshots, slides, and documents
- Send reminders and calendar invitations
- Publish the programme and speaker gallery
Underneath those workflows are a web application, versioned API, durable worker, identity boundary, PostgreSQL, Redis, object storage, observability, and recovery tooling.