PrismOS
Seven agents that are required to disagree before any code ships.
- Period
- 2026
- Role
- Product owner, architect, lead designer
- Status
- Live
I defined the agent-society model, owned the blueprint through three versions, and made the architectural and scope calls. Implementation was directed rather than hand-typed — I reviewed output and gave corrective feedback. The scope enforcement was the part that mattered: every capability added after v1.0 went in as a patch against working architecture, never a rebuild.
The problem
AI coding assistants are single-voiced. One model takes a feature request and decides everything itself — scope, architecture, implementation, testing — and it never disagrees with itself. The output compiles and demos well, and it quietly skips every tradeoff a real team would argue about.
The second failure is context. Most agent tools generate in a vacuum. They do not know what the codebase already looks like, what stack it runs on, or what was decided three features ago. The result is technically valid and architecturally foreign.
Why it mattersFeature delivery is a coordination problem before it is a code-generation problem. The value in a team comes from friction — the architect pushing back, QA refusing to sign off, the PM cutting scope. Strip that out and call the result autonomous development, and you have a demo rather than a delivery system.
What I built
Point PrismOS at a codebase and describe a feature. It reads the existing product, loads project memory from prior runs, activates seven specialized agents, streams their reasoning live, forces them into structured debate, resolves conflicts through a Release Manager, and returns a package: production-ready code, tests, a conflict log, a benchmark, and a binding SHIPPABLE or NEEDS_REVISION verdict.
The full surface shipped — landing page, dashboard, two-step run creation, a live seven-agent streaming view, project and session history, a conflicts explorer, a benchmark comparison, an architecture page, and a self-contained demo mode.
How it holds together
Run the pipeline. Step three is a parallel debate — three agents respond independently and are required to surface disagreement before the Release Manager rules.
Context ingestion runs before any model call. GitHub parsing, file reading and URL crawling are deterministic and synchronous, targeted under five seconds, so no tokens are spent on I/O.
Context is injected at the system-prompt level rather than as a user message, so it does not inflate the turn count for every downstream agent.
Conflict is mandatory rather than emergent. Step three requires disagreement, and structured markers — SECURITY FLAG, INTEGRATION RISK — drive orchestration. A security flag from QA is non-negotiable and routes to the Release Manager. An unopposed integration risk logs as a warning without triggering resolution.
With zero context supplied, Agent 0 emits a minimal summary and the workflow proceeds normally, preserving the original feature-request-only path.
Decisions
- 01
Agreement was the failure mode, not disagreement
Running seven agents was straightforward. Stopping them collapsing into polite consensus was not. Agents respond in parallel without seeing each other's output first, prompts require at least one surfaced disagreement, and the orchestrator routes on structured markers rather than on sentiment. Conflict had to be consequential or it was theatre.
- 02
The conflict log is the product
Code generation is commodity. What almost nothing offers is the reasoning trail — what was contested, who won, and why. A run returns the argument that produced the code alongside the code, which is auditability rather than output.
- 03
One revision cycle, maximum
QA can send work back once. After that the verdict stands, even if it is NEEDS_REVISION. An agent loop with no ceiling is a system that will happily spend your budget converging on nothing.
CostA genuinely fixable second-order defect ships flagged instead of fixed.
- 04
Patches over rebuilds, enforced
Agent 0, the UI/UX Designer, project memory, feature classification and frontend QA checks were all added after v1.0 — every one as an incremental patch against working architecture. Multiple proposed rebuilds were rejected. Auth, rate limiting and webhooks were cut and documented as deferred rather than half-built.
- 05
Serverless pivot mid-build
Started on Alibaba Cloud ECS and moved to Serverless App Engine once the operational overhead became a schedule risk, while keeping the Alibaba Cloud deployment requirement satisfied.
Stack
- LangGraph StateGraph
- FastAPI
- SSE streaming
- Qwen3-235B-A22B
- DashScope
- Next.js App Router
- TypeScript
- Tailwind v4
- Framer Motion
- EventSource
- Supabase
- PostgreSQL
- Alibaba OSS
- Alibaba Cloud SAE
- Multi-agent orchestration with real conflict generation and resolution
- Codebase-aware generation that fits an existing system
- Project memory that compounds across runs
- Seven concurrent token streams rendered legibly
- A quality gate that will refuse to ship