Skip to main content

Appgrammar

Appgrammar is an always-on AI Mesh of coding agents and live applications, powered by Appgrammars — compressed software blueprints (appgrammars) that any AI agent can follow to build and maintain software efficiently.

AI Mesh

Turn your development and infrastructure into a living network of connected AI coding agents and applications. Deploy apps that stay connected to the mesh — monitored and maintained by dedicated coding agents. Orchestrate multiple specialized agents per node.

Appgrammars

Appgrammars compress architectural knowledge into reusable software blueprints. An Appgrammar is a DAG (directed acyclic graph) of modules and steps that an agent follows deterministically, spending tokens only on the unique parts of your project. Unlike code, Appgrammars are composable, transferable, and mutable — operations impossible at the code level.

How It Works

  1. Create — Describe what you want to build. Appgrammar's 5-step pipeline generates the architecture, design system, task DAG, file registry, and enriched step descriptions.
  2. Execute — Your AI agent calls appgrammar_start and receives steps one at a time via appgrammar_next. Each step contains everything the agent needs: file paths, code specifications, and context.
  3. Compose — Appgrammars can be forked, bred, spliced, shattered, and recombined using 30+ tools organized around 7 axioms.
  4. Update — As you iterate on your codebase, appgrammar_update syncs the blueprint with reality — closing the feedback loop between the built application and the plan.

Core Concepts

Appgrammar

An appgrammar is a precompiled blueprint — a DAG of modules and steps that guides an AI agent through building an application:

  • Modules — logical groups of related functionality (e.g. "authentication", "database", "API routes")
  • Steps — individual build actions within a module (e.g. "create user model", "add login endpoint")
  • System prompt — context and conventions injected at execution start
  • Design system — UI framework, colors, typography decisions

Stages and Parallel Groups

During execution, steps are organized into stages. Each stage contains one or more parallel groups:

  • Groups within the same stage can run concurrently (no dependencies between them)
  • Steps within a group must run sequentially
  • The next stage only starts after all groups in the current stage complete

This structure maximizes parallelism while respecting dependency ordering.

Tokens

Execution uses single-use UUID tokens to chain stages. Each call to appgrammar_next consumes one token and returns the next token. This ensures steps are executed in order, no step is skipped or repeated, and execution state is tracked server-side.

The 5-Step Creation Pipeline

Every appgrammar is created through a 5-step pipeline:

  1. Architecture — Extract or generate the module graph, technology choices, and dependency structure
  2. Design System — Define the visual language: framework, colors, typography, component patterns
  3. Task DAG — Order the build steps, identify parallel groups, resolve dependencies
  4. File Registry — List every file to be created with its exports, imports, and role
  5. Enrichment — Generate compressed specifications for each build step

For existing codebases, the decompiler runs this same pipeline in reverse, analyzing source code to produce an appgrammar.

Conventions

Teams can define conventions — coding rules that get injected into the execution context when an agent runs a team-owned appgrammar. Conventions are matched by technology tags (e.g. ["typescript", "react"]) and formatted as markdown sections in the system prompt.

The 7 Axioms

Appgrammar's tool system is built on 7 axioms about software structure:

AxiomPrincipleTools
I — CompressionKnowledge compresses. Execution expands.create, decompile, holographic_doc
II — ContextAgent quality degrades with context size.start, next, swarm_partition, semantic_rollback
III — GovernanceUngoverned agents are liabilities.inoculation, phenotyping
IV — ArchitectureStructure is composable, forkable, heritable.breed, fork, splice, shatter, weave
V — EcosystemWhen intent is legible, the ecosystem is navigable.search, broadcast, topological_search, upstream_shield
VI — TransformationIntent is invariant under transformation.transmute, distill, amplify, style_transfer
VII — AlgebraStructure admits a closed algebra.subtract, intersect, difference, fuzz, update

Next Steps