Systems
One brief. One long-running agent loop. One working event platform.
Session Board began as a high-level competition brief. A Pi coding agent turned it into a multi-service application without active supervision, while ldgr kept the work structured across the full build.
The source
The starting document described the product, its primary workflows, and the result that entrants should deliver. It did not prescribe the implementation architecture.
The brief is public. It remains the clearest way to compare the starting point with the finished system.
The structure
A Pi agent performed the implementation. ldgr supplied the durable structure around that agent loop: bounded work, recorded runs, evidence, validation, and decisions.
That structure mattered because the system did not fit in one prompt or one context window. 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. Its original statuses describe the pre-execution plan, not the current implementation state.
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.