|
| 1 | +# Simplex |
| 2 | + |
| 3 | +A workflow specification language for autonomous agents. |
| 4 | + |
| 5 | +An observed trend in AI development is the creation of new programming languages designed specifically for LLM code generation. The premise is reasonable. LLMs make syntax errors and struggle with operator precedence, so cleaner languages with unambiguous syntax, mandatory testing, and minimal keywords should help. |
| 6 | + |
| 7 | +However, it addresses a problem that LLMs largely do not have. |
| 8 | + |
| 9 | +LLMs are excellent at syntax. They've seen billions of lines of code in every language. They rarely struggle with semicolons, brackets, or operator precedence. 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. |
| 10 | + |
| 11 | +The real bottleneck lies not in code generation, but in specification: expressing what we want clearly enough for autonomous systems to act on without constant clarification. |
| 12 | + |
| 13 | +## Inverting the Problem |
| 14 | + |
| 15 | +Rather than making code easier for LLMs to write, what if we made specification easier for humans to write, consistent across teams in large organizations, and rigorous enough for LLMs to act on without clarification? |
| 16 | + |
| 17 | +Humans will always be the specifiers. We know what we want to build. The question is how to express that knowledge in a form that autonomous agents can execute reliably over hours or days without human intervention. |
| 18 | + |
| 19 | +Natural language tends to be too ambiguous for reliable autonomous execution, while programming languages are too prescriptive. What seems to be needed is something in between: a specification language that captures intent and constraints without dictating implementation. |
| 20 | + |
| 21 | +## What Simplex Is |
| 22 | + |
| 23 | +Simplex is a specification language 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. |
| 24 | + |
| 25 | +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. |
| 26 | + |
| 27 | +Here is an example specification for an e-commerce checkout system: |
| 28 | + |
| 29 | +```yaml |
| 30 | +FUNCTION: process_checkout(cart, customer, payment) → CheckoutResult |
| 31 | + |
| 32 | +RULES: |
| 33 | + - verify cart is not empty and all items are in stock |
| 34 | + - validate customer shipping address with postal service |
| 35 | + - apply discount codes and calculate final total |
| 36 | + - authorize payment for the calculated amount |
| 37 | + - reserve inventory for purchased items |
| 38 | + - generate order confirmation with tracking number |
| 39 | + |
| 40 | +DONE_WHEN: |
| 41 | + - order is persisted with confirmed payment, or |
| 42 | + - checkout fails with specific reason at point of failure |
| 43 | + |
| 44 | +EXAMPLES: |
| 45 | + (valid_cart, verified_customer, good_card) |
| 46 | + → { success: true, order_id: "ORD-12345", total: 99.50 } |
| 47 | + (empty_cart, any, any) |
| 48 | + → { success: false, reason: "cart is empty" } |
| 49 | + (valid_cart, unverified_address, any) |
| 50 | + → { success: false, reason: "address verification failed" } |
| 51 | + (valid_cart, verified_customer, declined_card) |
| 52 | + → { success: false, reason: "payment declined" } |
| 53 | + |
| 54 | +ERRORS: |
| 55 | + - payment gateway timeout → retry once, then fail with "payment unavailable" |
| 56 | + - inventory changed during checkout → fail with "cart contents changed" |
| 57 | + - any unhandled condition → fail with descriptive message |
| 58 | +``` |
| 59 | +
|
| 60 | +Six pillars guide the design: |
| 61 | +
|
| 62 | +**Enforced simplicity** requires that complex specifications be decomposed into smaller pieces. If something cannot be expressed simply, it is not yet understood well enough to specify. |
| 63 | +
|
| 64 | +**Syntactic tolerance, semantic precision** means the language forgives typos and formatting inconsistencies while requiring unambiguous meaning. |
| 65 | +
|
| 66 | +**Specification, not implementation** means describing what and constraints, never how. Agents choose their own approach. |
| 67 | +
|
| 68 | +**Testability** requires concrete examples for every function. These serve as contracts and ground truth. |
| 69 | +
|
| 70 | +**Completeness** requires that specifications be sufficient without clarification. No back-and-forth, no requests for additional context. |
| 71 | +
|
| 72 | +**Implementation opacity** means the spec describes contracts. Whether agents implement a data store as a graph database or a file system is their concern, not the spec's. |
| 73 | +
|
| 74 | +## Why This Matters |
| 75 | +
|
| 76 | +Autonomous agent workflows are maturing. Agents now work for extended periods, hours or days, developing applications, iterating on solutions, evaluating versions among themselves, and producing release candidates. These workflows need instructions that are complete enough to act on yet flexible enough to allow emergent problem-solving. |
| 77 | +
|
| 78 | +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. |
| 79 | +
|
| 80 | +Perhaps what matters most is not how LLMs write code, but how humans express what they want built. A specification language 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. |
0 commit comments