Simplex

Simplex is a workflow specification for autonomous agents. It describes what needs to be done and how to verify completion, without prescribing how to do it. Agents receive instructions complete enough to act on for extended periods, yet flexible enough to allow emergent problem-solving.

Read the Spec See Examples

Simplex is research infrastructure for studying emergent software architecture in agent swarms. The spec's generality and vagueness about implementation detail and coordination is intentional. The enforced simplicity functions as an experimental control to study outputs of Simplex-driven workflows.

The Specification Gap

What's missing between human intent and agent execution

An observed trend in AI development is the creation of new programming languages optimized for LLM code generation. The premise is reasonable: LLMs make syntax errors and struggle with operator precedence, so cleaner languages with unambiguous syntax should help.

However, this is a problem that LLMs largely do not have.

LLMs are excellent at syntax. They've seen billions of lines of code in every language. What they struggle with is understanding intent, constraints, and edge cases. A new language with cleaner syntax addresses the easy part while leaving the hard part, specification, entirely in natural language prompts.

The real bottleneck lies not in code generation, but in specification: expressing what we want clearly enough for autonomous systems to act on without interactive clarification.

What Simplex Is

Simplex is a specification for autonomous agents that describes work rather than workers, capturing what needs to be done and how to know when it's done without prescribing how to do it.

The language has no formal grammar. It uses landmarks, structural markers like FUNCTION, RULES, DONE_WHEN, and EXAMPLES, that LLMs recognize and interpret directly. Syntax is forgiving; meaning must be precise.

Example: E-commerce Checkout

FUNCTION: process_checkout(cart, customer, payment) → CheckoutResult

RULES:
  - verify cart is not empty and all items are in stock
  - validate customer shipping address with postal service
  - apply discount codes and calculate final total
  - authorize payment for the calculated amount
  - reserve inventory for purchased items
  - generate order confirmation with tracking number

DONE_WHEN:
  - order is persisted with confirmed payment, or
  - checkout fails with specific reason at point of failure

EXAMPLES:
  (valid_cart, verified_customer, good_card)
    → { success: true, order_id: "ORD-12345", total: 99.50 }
  (empty_cart, any, any)
    → { success: false, reason: "cart is empty" }
  (valid_cart, unverified_address, any)
    → { success: false, reason: "address verification failed" }

ERRORS:
  - payment gateway timeout → retry once, then fail
  - inventory changed during checkout → fail with "cart contents changed"
  - any unhandled condition → fail with descriptive message

Six Pillars

Enforced Simplicity

Complex specifications must be decomposed into smaller pieces. If something cannot be expressed simply, it is not yet understood well enough to specify.

Syntactic Tolerance

The language forgives typos and formatting inconsistencies while requiring unambiguous meaning. Sloppy notation is acceptable; vague meaning is not.

Specification, Not Implementation

Describe what and constraints, never how. Agents choose their own approach to solving the problem.

Testability

Concrete examples are required for every function. These serve as contracts and ground truth for agent behavior.

Completeness

Specifications must be sufficient without clarification. No back-and-forth, no requests for additional context.

Implementation Opacity

The spec describes contracts. Whether agents implement a data store as a graph database or a file system is their concern.

Why This Matters

Autonomous agent workflows are maturing. Agents now work for extended periods, developing applications, iterating on solutions, evaluating versions among themselves, and producing release candidates. These kinds of workflows need instructions that are complete enough to act on yet flexible enough to allow emergent problem-solving.

Simplex is designed for this context: a human writes a specification that agents interpret, decompose, and execute autonomously. The specification serves as the contract between human intent and machine action.

Perhaps what matters most is not how LLMs write code, but how humans express what they want built. A specification designed for human authors, one that captures intent precisely enough for autonomous agents to act on, may prove more valuable than any improvements to code generation itself.