Gyre Platform

Gyre is a platform for designing, building, and maintaining apps that ship.

Gyre's code generation pipeline simultaneously generates Fabric — an atomic claims-based substrate woven from design documents, agent sessions, code, schema, architecture decisions, AST analysis, tests, observability, and more.

Fabric builds developer trust in AI-generated code and gives teams a variety of lenses through which to understand, verify, and maintain what they've built.

scroll to explore
01
The wrong layer of abstraction
Every existing approach is solving the wrong problem. Until you identify the right layer, you can't know what the tools should look like.
+

In 2024, METR ran a randomized trial with experienced developers using AI coding tools on real issues in repositories they knew well. They expected to be 24% faster. They estimated they were 20% faster. They were 19% slower.

The slowdown wasn't AI failing to generate good code. It was developers trying to verify AI-generated code with instruments designed for writing it. Every tool in this space has taken a position on trust. None have found the right layer.

Fitting old processes to new realityAgile, Shape Up, spec-driven development — workflows designed for humans writing code. Grafting them onto AI-generated output doesn't address what changed. The process metaphors don't match the underlying mechanics.
Orchestrating agents and hopingCoordination is not verification. More agents producing more output faster means more to understand, not less — with the same broken instruments. Having an agent verify another agent's work produces a judgment made by the same class of system that generated the code.
AI-assisted IDEsCursor, Copilot, Windsurf. These correctly identify that developers need help but place the help at the code-production layer, which is no longer the bottleneck.

The right layer is verification and comprehension. Once you're operating there, the tools become clear: typed claims, not prose specs. Epistemic observability, not just runtime observability. A substrate that accumulates verified understanding, not just a context window that forgets.

02
What Gyre builds
Code and Fabric, simultaneously — plus the claims, concepts, and gates that make both trustworthy.
+

Every codegen run in Gyre produces two things simultaneously: code and Fabric. Code goes into your git history. Fabric is a living, graph-structured verification substrate co-produced with the code — verified against it for drift, designed to be consumed faster than code because it operates at a higher level of abstraction.

Claims are the atomic unit of verification — typed, structured assertions about what code is, does, must not do, and how it performs. The machine verifies what the machine can verify. Human attention is reserved for the residual that genuinely requires judgment. You are never asked to verify what the system could verify on its own.

structural → AST analysis behavioral → tests constraint → hooks + scans operational → observability

Concepts organize the project's vocabulary from vision down to ground-level implementation, connected by typed relationships with formal properties. Every decision records what the world looked like when it was made, the assumptions it rested on, and the conditions that should trigger revisiting it. Alternatives — roads not taken — are tracked and searchable.

Custodial agents maintain the substrate automatically. Knowledge enters Fabric as a byproduct of building. Nobody has to remember to write it down.

Gyre is an AIDE — an AI Development Environment — built for the job that actually exists right now: not writing code, but knowing whether to trust it.

03
What it produces
A live epistemic view of your codebase — what's known, what's uncertain, what's never been verified — at design time, delivery time, and debugging time.
+

Fabric projects into multiple views of the application — code, schema, intention, decisions, contracts, discovered workflows, concept wiring, verification coverage. Each view is derived from the underlying graph, not authored separately. They stay consistent by construction.

Epistemic observability is the third instrument alongside runtime and pipeline observability: does our understanding of the code match the code itself? The result is a confidence heatmap across the entire application surface — deep green where verification is current, red where changes have likely invalidated what we thought we knew, grey where no one has ever verified at all. The system makes its own blind spots visible.

The Fabric Host makes the substrate inhabitable. Ask your codebase a question — why does the auth middleware use token bucket? — and get an answer assembled from graph traversal: the session where it was conceived, the decision that chose token bucket over sliding window, the alternatives considered, the assumptions it rested on, and whether any have since been invalidated.

At Gate B, the human reviewer receives an assembled case file — not a code diff. Claims tell them what the code should do. Decisions tell them why it was designed this way. Drift findings tell them where alignment broke down. The human drops to code only when Fabric signals something that needs direct inspection.

04
How it compares
Augment built two layers of what Gyre unifies. Their substrate is quicksand. Gyre's atomic claim is the fixed point.
+

The most serious team in this space is Augment Code — $252M raised, $977M valuation, shipping at enterprise scale. Their Context Engine (semantic indexing across 400,000+ files) and Intent product (multi-agent orchestration with living specs) approximate two layers of what Gyre is building. Gyre unifies both around a different semantic center: the atomic claim.

Intent's living spec auto-updates as agents implement. Augment's own documentation confirms the mechanism: when an agent completes work, the spec updates to reflect what was actually built. At any point in an Intent project, there is no way to distinguish whether the spec reflects original design intent or accumulated implementation decisions. The spec converges on what was built. That is the intended behavior — and it is also the limitation.

Prose is quicksand. The more you build on it, the less stable the ground becomes.

Gyre's atomic claim is the fixed point. Claims don't update to match code — they maintain the original assertion and report a verification status. If a claim fails, you know the code diverged from intent. That gap cannot be papered over by a self-updating prose document.

Agent verification is not verification. Gyre verifies deterministically wherever possible. Human attention is reserved for the residual that genuinely cannot be verified any other way — and that residual is smaller than you think.

Augment is further along operationally. The architectural gap runs the other direction.

05
Where it stands
The substrate, pipeline, and gates are built and working. The enterprise layer needs a partner.
+

Built and working: End-to-end codegen pipeline through claim extraction, code generation, deterministic verification, and Gate B review. Writing Room multi-agent authoring environment. Blueprint concept graph with typed relationships. Tapestry including graph projection and custodial agents. Fabric MCP server. AST analyzers for TypeScript and Python.

Implementation ahead: Fabric Host (conversational RAG over the verified substrate), epistemic observability heatmap, full drift patrol with auto-heal policies, interactive workflow visualization, decision revisit evaluation.

Known gaps — where a partner is needed:

Multi-user and team primitives. Single-user today. Multiplayer semantics — shared Fabric state, conflict resolution at gates, role-based views — are a design-level gap not yet closed.
Enterprise authentication, authorization, and audit. SSO, RBAC, fine-grained permissions, audit trails. Not built. Not my area.
Security hardening. An adversarial review from someone who has shipped security-sensitive enterprise products would find things that have been missed.
On-premise and private-cloud deployment. Enterprise customers will want data isolation. The current architecture is cloud-hosted; on-prem is a real engineering commitment not yet scoped.
06
What we're looking for
Two things.

Feedback on the concept. Where is the thesis wrong? Where is the architecture shakier than it looks? Where is the competitive positioning off? Specific, argumentative feedback is more useful than encouragement. If you read this and think "this is missing X" or "Y is a bigger problem than you realize" — that is exactly what is needed.

A CTO / cofounder with experience shipping to enterprise. The right person has shipped software that serves teams and organizations, has real exposure to security reviews and procurement, understands how collaborative software breaks in the field, and has strong opinions about multi-user state, permissions, and audit. They see in the architecture above a platform worth building.

The product's current shape is strong in the parts that are clearly visible — the semantic substrate, the pipeline, the human-factors framing, the formal logic underlying claims. The parts that aren't visible clearly have been deferred. A partner is needed to carry those parts, not an employee to execute on them.