The Agentic Web Standard

"Spring Boot for Agentic Web Development" Status: Concept / Pre-specification Date: December 21, 2025

Executive Summary

This document outlines a specification-first approach to creating an opinionated standard for building web applications that AI can reliably generate, modify, and maintain.

The thesis: The future of web development isn't a new framework—it's a set of conventions that make existing tools AI-composable.

Why a Standard, Not a Framework

Historical Precedent

The Current Landscape

The agentic web development space is fragmented:

Nobody owns the full stack for agentic web development.

Why Specification-First Wins

1. Framework-agnostic - Works with Next.js today, Phoenix tomorrow
2. Adoption path - Teams adopt conventions without rewriting
3. Ecosystem growth - Others can build implementations
4. AI training - Specification becomes training data

What Made Spring Boot / Rails Win

Spring Boot's Success Formula

"Spring Boot embraces 'opinionated defaults' based on best practices... reduces cognitive load... developers can still override but out-of-the-box setup is sufficient"

Key principles:

• Auto-configuration - Sensible defaults from dependencies
• Convention over configuration - Decisions made for you
• Starter packages - Curated dependency bundles
• Override when needed - Flexibility within opinions

Rails Doctrine

"You're not a beautiful and unique snowflake... by giving up vain individuality, you can leapfrog mundane decisions"

Key principles:

• Optimize for programmer happiness
• Convention over configuration
• The menu is omakase - Trust the chef
• No one paradigm - Pragmatic, not dogmatic

The Common Thread

Neither invented new languages. They made opinionated decisions about existing tools:

• Rails = Ruby + ActiveRecord + ERB + conventions
• Spring Boot = Java + autoconfiguration + starters

The Agentic Web Standard: Core Conventions

Convention 1: Finite Component Registry

AI should select from components, not invent them.

{
  "registry": {
    "ProductCard": {
      "description": "Display a product with image, title, price",
      "props": { "$ref": "#/schemas/ProductCardProps" },
      "variants": ["compact", "detailed", "featured"],
      "capabilities": ["display-product", "add-to-cart"]
    }
  }
}

Rationale: A2UI and AG-UI both converge on this. Declarative registries are the "sweet spot" - variety without chaos.

Convention 2: Server-First State

All state lives on the server. No client-side state management.

// YES: Server action
async function addToCart(productId: string) {
  'use server';
  return db.cart.add(productId);
}

// NO: Client state
const [cart, setCart] = useState([]);

Rationale: HTMX reduced codebases by 67% vs React. LiveView eliminates entire classes of bugs. AI struggles with hooks/effects.

Convention 3: Typed Primitives

All functions have typed input/output with Zod schemas.

const createOrder = primitive({
  name: 'createOrder',
  description: 'Create a new order from cart items',
  input: z.object({
    cartId: z.string(),
    shippingAddress: AddressSchema,
  }),
  output: z.object({
    orderId: z.string(),
    total: z.number(),
  }),
  execute: async (input) => { ... }
});

Rationale: AI can reason about types. Schemas become documentation. Property-based tests derive from types.

Convention 4: Workflow State Machines

Complex flows are explicit state machines, not implicit control flow.

const checkoutWorkflow = workflow({
  name: 'checkout',
  states: ['cart', 'shipping', 'payment', 'confirmation'],
  transitions: {
    cart: { next: 'shipping', validate: validateCart },
    shipping: { next: 'payment', validate: validateAddress },
    payment: { next: 'confirmation', validate: processPayment },
  }
});

Rationale: AI can parse state machines. Explicit states prevent bugs. Testing is deterministic.

Convention 5: Property-Based Test Generation

Types generate tests automatically.

// From the primitive definition, generate:
test.property('createOrder respects cart total',
  fc.record({ cartId: fc.uuid(), shippingAddress: addressArbitrary }),
  async (input) => {
    const result = await createOrder.execute(input);
    expect(result.total).toBeGreaterThanOrEqual(0);
  }
);

Rationale: AI can't verify its own output. Property tests catch edge cases. Types encode invariants.

Convention 6: File-Based Everything

Structure is in the filesystem, not configuration.

app/
├── components/          # Registry auto-discovered
│   ├── ProductCard.tsx
│   └── ProductCard.schema.ts
├── primitives/          # Functions auto-discovered
│   ├── createOrder.ts
│   └── processPayment.ts
├── workflows/           # State machines auto-discovered
│   └── checkout.ts
└── routes/              # Already standard (Next.js, SvelteKit)

Rationale: AI can navigate filesystem. No hidden configuration. Discovery is deterministic.

What the Standard Includes

1. Component Registry Specification

JSON Schema defining:

• Component metadata (name, description, capabilities)
• Props schema (Zod-compatible)
• Variants and states
• Accessibility requirements
• AI composition hints

2. Primitive Function Interface

TypeScript interface defining:

• Input/output schemas
• Description for AI
• Execution function
• Optional rollback
• Validation hooks

3. Workflow State Machine Format

JSON Schema defining:

• States and transitions
• Validation at each step
• Error handling
• Persistence strategy

4. Test Generation Protocol

Specification for:

• Deriving property tests from types
• Coverage requirements
• AI verification hooks

Implementation Strategy

Phase 1: Define the Specification (Q1 2025)

Deliverables:
├── component-registry.schema.json
├── primitive-function.schema.json
├── workflow-state-machine.schema.json
├── test-generation.schema.json
└── conventions.md

Phase 2: Build Reference Implementation (Q2 2025)

Deliverables:
├── @agentic-web/core          # Shared types and utilities
├── @agentic-web/nextjs        # Next.js conventions
├── create-agentic-app         # CLI scaffold
└── vscode-agentic-web         # VS Code extension

Phase 3: Expand Implementations (Q3-Q4 2025)

Deliverables:
├── @agentic-web/sveltekit     # SvelteKit version
├── @agentic-web/phoenix       # Phoenix LiveView version
├── @agentic-web/htmx          # Go + HTMX version
└── claude-code-integration    # Native Claude Code support

Competitive Positioning

vs v0 / Bolt / Lovable

vs LangChain / AutoGen

vs AG-UI / A2UI

Why This Will Win

1. Timing

The "vibe coding hangover" is creating demand:

• 45% of AI-generated code has security vulnerabilities
• Senior engineers burning out on AI-generated spaghetti
• Even Karpathy abandoned vibe coding for his latest project

2. Market Gap

No one owns "Rails for AI-generated apps":

• Microsoft is enterprise-focused (Azure AI Foundry)
• Vercel is platform-focused (v0)
• Anthropic is protocol-focused (MCP)

3. Adoption Path

Teams can adopt incrementally:

1. Add component registry to existing Next.js app
2. Convert functions to typed primitives
3. Extract workflows to state machines
4. Enable test generation

No rewrite required.

Naming Considerations

Recommendation: Forge - aligns with signal-forge, implies crafting/building, suggests transformation.

Next Steps

1. Validate with community - Share thesis, gather feedback
2. Draft specifications - Start with component registry
3. Build proof-of-concept - Extract from bc-migration
4. Create scaffold - npx create-forge-app
5. Write manifesto - "The Forge Doctrine" (like Rails Doctrine)

Sources

• Spring Boot Opinionated Defaults
• The Ruby on Rails Doctrine
• Convention over Configuration
• Microsoft Build 2025: The Age of AI Agents
• Azure Agent Factory
• AI Prototyping Tools Comparison
• Lovable vs Bolt vs V0