This organization holds the shared pieces we use to build and run internal Platform apps at Plain Concepts. Agents do a large share of the work, so most of what is here exists to make that safe rather than just fast: a design system, a harness that prepares a repository for agents, the workflows that run them, and the metrics that say whether any of it worked.
The documentation is at platform.plainconcepts.com.
Our apps go through three phases. What separates them is who is allowed to start a change, and each phase hands that right to a wider group.
- Discovery. We decide what to build with the departments that will use it, together with the integrations it needs and the constraints it has to respect. The constraints matter most, because they become guardrails in the next phase.
- Foundations. Engineers and agents build the app, and the guardrails that bind everything after it: layering rules that fail the build when crossed, specifications that must be updated when behaviour changes, a test quality gate that rejects tests asserting nothing, an audit trail with no bypass.
- Maintenance mode. People in the business file bugs and small feature requests, and agents implement them. Inside an eligible scope, no engineer is in the loop.
The order is not a preference. Phase 2 is what makes phase 3 safe: a request reaches production without a reviewer only because the guardrails are constraints an agent cannot argue its way past. Skip that work and you do not get a maintenance mode, you get a fast way to generate incidents.
Where the line sits between what the business can request and what stays an engineering decision is drawn by category rather than by size. Anyone can ask for a change to an outcome, meaning how a screen behaves, what a workflow does, what the wording says, or what a business rule computes. Architecture, infrastructure, authentication, data models and APIs stay with engineering, even when the request is small and clear.
The full version is in How we work.
| Repository | What it does |
|---|---|
| Foundations | The design tokens, the frontend and .NET conventions, the reference architecture, and the docs site. |
| agent-harness | Installs the Platform Harness into a repository: skills, slash commands, an agent team, and an OpenSpec workspace. |
| agentic-workflows | The router and worker catalog that runs the pipeline, plus the CLI that installs and updates it. |
| project-health | Delivery and agent metrics collected from GitHub, published as a static site. |
They read as a chain, which is the clearest way to see why there are four rather than one. Foundations sets the conventions. agent-harness puts them into a repository as something agents can act on. agentic-workflows runs the agents against it. project-health reports on what came out. Drop any one and the phase it carries stops working.
Once agents implement most of the changes, throughput stops being informative. A project can open forty pull requests in a week and mean nothing by it, so the numbers we care about are how much still needs a person, what the agents cost in tokens, and which metrics we cannot honestly produce at all.
Three DORA metrics come from a repository. Two do not, because they depend on knowing that a release caused a problem in production, which is a fact about the running service. We report those as not collected rather than substituting a red pipeline for an incident. A missing metric is a fact about the data, not a gap to fill with a plausible number.
That reasoning is written up in DORA in an agentic world.
loop-task runs any command on a cadence. It is the fallback for work with no repository event to react to, not the default. If the trigger is something happening in the repository, agentic-workflows is the right tool.
Install the theme and get a themed app running:
pnpm add @plainconceptsplatform/ui-theme @plainconceptsplatform/ui-components tailwindcssPrepare a repository for agents:
npx @plainconceptsplatform/agent-harness@latestThen install the workflows that drive it:
npx @plainconceptsplatform/workflowsThe quickstart covers the first path, and AI covers the other two, including which runner to use and why the default is GitHub Actions rather than a long-lived local loop.