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.

github.com/hydra-dynamix/grist

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.

github.com/hydra-dynamix/agentctl

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.

github.com/hydra-dynamix/erasmus-3

Erasmus pipeline interface showing an agent, text-to-speech, speech-to-text, and a model-output parser in one workflow
One pipeline combining an agent with speech and parsing steps. Each step shows its input, its output, and its state.

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.

Read about the products.

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.