The Praxys Design Agency: a controlled loop from intent to application

Praxys Design Agency is designed to make that chain a single, controlled loop. A customer describes the outcome they want. A design architect establishes a coherent direction. The compiler turns that direction and the project state into a proposed change. Verification and repair test the proposal before it reaches review. The customer remains the decision-maker at the point that matters: accepting, refining, or rejecting the change.

This is not code autocomplete. It is a system for carrying intent through design, implementation, verification, preview, and deployment without treating them as unrelated steps.

Start with a design contract

The loop begins with the design architect—called the Art Director in the compiler. When enabled for a Studio session, it reads the customer prompt, the existing project or source specification, and the available design catalog. It produces a schema-validated Design Brief before frontend generation begins.

The brief is not a mood board. It records decisions the rest of the pipeline can use and check: the application archetype, visual tone and density, screen inventory, layout grammar, selected design-system blocks, microcopy voice, imagery direction, motion preferences, and, where needed, locale direction.

That makes design direction executable. The Art Director chooses from real blocks and approved visual packs rather than asking a downstream generator to invent an interface from a vague adjective. The brief is validated and checked against the catalog, so a reference to a nonexistent building block is caught before it becomes a broken screen. It is then passed to the builders and verifier as a shared contract.

Build across the whole application

The Foundry Compiler takes a customer prompt and the current project state, then decomposes the work into a plan. Specialist agents handle the parts of an application that benefit from distinct expertise: schema design, backend behavior, frontend implementation, security review, deployment configuration, documentation, and tests.

The compiler coordinates these tasks and assembles their output into a ProjectDiff: a concrete, reviewable set of proposed changes rather than an opaque rewrite of the project. This matters for existing applications. A change can be traced, discussed, applied through the project's collaboration flow, and previewed without surrendering control of the codebase.

The design brief stays present throughout the process. It directs the frontend builder toward the intended blocks, tokens, and content style; it gives test generation useful context about expected screens and behavior; and it allows the verifier to distinguish a deliberate design from a generic fallback.

Verify, then repair

Generation is only the first pass. The compiler runs a verifier over the proposed files and sends specific failures back to a repairer. The repair loop is bounded: it rechecks after each targeted fix and escalates with the final verdict if it cannot produce a passing proposal within its configured limit.

Several checks are structural. The compiler rejects unsupported application patterns, enforces the platform's TypeBox schema convention, and verifies tenant scoping in database-query patterns. When a Design Brief is present, it also checks that required design-system blocks are actually composed, and that committed accessibility choices such as right-to-left direction or reduced-motion support are not silently dropped.

Additional conformance hooks can strengthen the loop further. A type-check gate validates the generated application before review. A boot-smoke gate materialises the output, starts it in a subprocess, and probes its core routes. These checks catch issues that an AST-only pass cannot: dead imports, type errors, missing runtime wiring, and startup failures. A failed check becomes repair input, not an invisible defect passed to the customer.

Previews and screenshots add a complementary review surface. They let customers compare generated variations and inspect a real rendered application, while the platform keeps the preview and review lifecycle separate from the compiler's core generation logic.

The loop at a glance

⤢ enlarge

×

The point of the loop is continuity. The same intent that shaped the design brief informs implementation; the same contract that guided generation supplies verification criteria; and the same project change that is reviewed can move into the hosting workflow. The platform does not ask a customer to translate design into engineering, then translate engineering into deployment by hand.

Human judgment remains part of the system

Automation is most useful when it removes mechanical work without pretending to remove responsibility. Customers still set the direction, review the outcome, choose integrations and business rules, and decide when a change is ready to deploy. The Design Agency reduces the distance between those decisions by doing the planning, cross-layer implementation, and repeatable checks in between.

That is the role of the Praxys Design Agency: not to replace a product team with a black box, but to give every customer a disciplined loop that turns intent into a reviewable, testable, and deployable application.