The Universal Algorithm: How One Framework Scales from Bug Fixes to Building Companies

What if one algorithm could handle everything—from fixing a typo to architecting a distributed system to building an entire company? Not a vague philosophy, but a precise, verifiable framework with measurable progress tracking.

I spent six months building Personal AI Infrastructure (PAI) v2.1, an agent execution system that uses the same algorithm whether you’re debugging a function or designing multi-year product strategies. The breakthrough wasn’t in finding a universal algorithm—it was in discovering that the algorithm was already universal. We just needed to see it clearly.

The Problem with Task-Specific Thinking

Most developer tools operate on the assumption that different problems require different approaches. You have one workflow for fixing bugs, another for writing features, a third for architectural planning. Each context switch requires mental overhead—different commands, different tools, different mental models.

I noticed this pattern while watching myself work. When debugging, I’d follow an implicit process: observe the error, understand the code, plan a fix, implement it, verify it works. When architecting a new system, the same pattern emerged at a different scale: observe requirements, think through constraints, plan the architecture, build components, verify integration, learn from results.

The structure was identical. Only the scope changed.

This realization led to a question: what if we could formalize this pattern into a single algorithm that works at every scale?

The Universal Algorithm: Current → Ideal via Verifiable Iteration

The core insight is deceptively simple:

Every task is a gap between current state and ideal state, closed through verifiable iteration.

This translates into seven phases that repeat until completion:

graph LR
    OBSERVE[OBSERVE<br/>Current State] --> THINK[THINK<br/>Analyze Gap]
    THINK --> PLAN[PLAN<br/>Define Steps]
    PLAN --> BUILD[BUILD<br/>Create Artifacts]
    BUILD --> EXECUTE[EXECUTE<br/>Take Action]
    EXECUTE --> VERIFY[VERIFY<br/>Measure Progress]
    VERIFY --> LEARN[LEARN<br/>Update Context]
    LEARN --> OBSERVE

    style OBSERVE fill:#e3f2fd
    style THINK fill:#f3e5f5
    style PLAN fill:#fff3e0
    style BUILD fill:#e8f5e9
    style EXECUTE fill:#fce4ec
    style VERIFY fill:#e0f2f1
    style LEARN fill:#f1f8e9

Phase 1: OBSERVE - Establish Current State

Every iteration begins with ruthless clarity about where you are. Not where you think you are, or where you should be—where you actually are.

For a bug fix, this means reading error messages, examining stack traces, understanding the failing behavior. For system architecture, this means auditing existing services, measuring current performance, documenting constraints.

The OBSERVE phase produces artifacts:

Current state measurements (performance metrics, test results, user feedback)
Constraints (technical debt, dependencies, compliance requirements)
Available resources (time, budget, team capacity)

Critical principle: Observations must be verifiable. “The system is slow” is not an observation. “API p95 latency is 2.3 seconds, target is 500ms” is an observation.

Phase 2: THINK - Analyze the Gap

With current state established, THINK identifies what’s missing and why. This is pattern recognition, root cause analysis, and strategic thinking combined.

For a bug, THINK traces causality: what code path produces the error? What conditions trigger it? What invariants are violated?

For architecture, THINK examines trade-offs: what capabilities are missing? What bottlenecks exist? What technical decisions created the current constraints?

The THINK phase produces:

Root cause analysis
Constraint identification
Alternative approaches
Risk assessment

Key insight: THINK doesn’t make decisions—it surfaces options. Decision-making happens in PLAN.

Phase 3: PLAN - Define Verifiable Steps

PLAN converts analysis into actionable steps with explicit success criteria. Every plan must answer three questions:

What are we building? (Specific deliverables)
How do we know it works? (Verification criteria)
How much effort does this require? (Resource allocation)

Plans are hierarchical. A company-building plan contains multiple system-architecture plans, which contain multiple feature-development plans, which contain multiple bug-fix plans.

The PLAN phase produces:

Ordered task list with dependencies
Ideal State Criteria (ISC) for verification
Effort classification (TRIVIAL → DETERMINED)
Model selection for execution

Phase 4: BUILD - Create Artifacts

BUILD is where we create the things needed for execution. For code, this means writing functions, tests, documentation. For systems, this means designing APIs, data models, deployment configurations. For companies, this means drafting strategy documents, hiring plans, financial models.

BUILD is distinct from EXECUTE. You build a migration script (BUILD) before you run it against production (EXECUTE). You build a pitch deck (BUILD) before you present it to investors (EXECUTE).

The BUILD phase produces:

Code, tests, configurations
Documentation, diagrams, specifications
Scripts, automation, tooling
Communications, presentations, reports

Phase 5: EXECUTE - Take Action

EXECUTE runs the artifacts from BUILD in the real world. This is where you actually ship code, migrate databases, deploy infrastructure, send emails, make decisions.

EXECUTE is the only phase that changes external state. All other phases operate on information and plans.

The EXECUTE phase produces:

State changes (deployed code, sent messages, created resources)
Execution logs and traces
Immediate feedback from actions taken

Phase 6: VERIFY - Measure Progress

VERIFY compares outcomes against Ideal State Criteria defined in PLAN. This isn’t subjective—every ISC is a boolean condition that evaluates to true or false.

For code:

ISC 1: All unit tests pass
ISC 2: Existing features still work
ISC 3: API latency under 500ms at p95

For architecture:

ISC 1: System handles 10k concurrent users
ISC 2: Uptime exceeds 99.9%
ISC 3: All services emit metrics

VERIFY produces a gap analysis: which criteria are met, which aren’t, what’s the delta.

Phase 7: LEARN - Update Context

LEARN converts the iteration’s results into knowledge that informs future iterations. This is where you update your mental model, document discoveries, refine estimates, adjust plans.

What worked? What didn’t? What surprised you? What assumptions were wrong?

The LEARN phase produces:

Updated context and assumptions
Refined estimates for remaining work
Documentation of decisions and rationale
Trigger for next iteration (continue loop or exit)

ISC Tracking: Measuring the Gap

The Ideal State Criteria (ISC) system is what makes this framework verifiable. Every task defines upfront what “done” means as a set of boolean conditions.

Here’s a real example from a database migration task:

Migration ISC Criteria:

New schema deployed to staging (verifiable via SQL query)
All user records migrated (count matches source table)
Data integrity checks pass (0 mismatches found)
Rollback procedure verified (returns data to original state)

After each iteration, we evaluate all criteria and update status. Progress is mechanical: count of completed criteria divided by total criteria.

When progress reaches 100%, the task is complete. Not “probably done” or “looks good enough”—provably complete because all defined success criteria are met.

The Ralph Loop: Persistent Iteration Until Completion

The Universal Algorithm becomes powerful when wrapped in what I call the Ralph Loop—named after the principle of relentless pursuit until verified completion.

The loop executes one full cycle of the seven phases, then checks ISC status. If criteria remain unmet, it loops again. And again. Until either:

All ISC criteria are satisfied (success)
An unresolvable blocker is encountered (requires external intervention)
Max iterations are reached (prevents infinite loops on time-boxed tasks)

For DETERMINED tasks like building companies, max iterations is effectively infinite. The loop persists across days, weeks, months—however long it takes to satisfy all criteria.

Effort Classification and Model Selection

Not all tasks require the same resources. PAI defines five effort levels that determine both iteration depth and model selection:

TRIVIAL (1-2 iterations, Haiku)

Simple, well-defined tasks with obvious solutions
Examples: typo fixes, config updates, adding a log statement
Model: Claude Haiku (fast, cheap, sufficient for straightforward work)
Max iterations: 3

QUICK (3-5 iterations, Haiku/Sonnet)

Straightforward tasks requiring some analysis
Examples: implementing a simple function, writing a test, fixing a bug
Model: Haiku for OBSERVE/THINK, Sonnet for complex BUILD
Max iterations: 10

STANDARD (5-15 iterations, Sonnet)

Typical feature development with moderate complexity
Examples: building a REST endpoint, refactoring a module, optimizing a query
Model: Sonnet for all phases
Max iterations: 25

THOROUGH (15-50 iterations, Sonnet/Opus)

Complex features requiring deep analysis and careful verification
Examples: designing a new service, implementing security features, complex migrations
Model: Sonnet primary, Opus for critical THINK/VERIFY phases
Max iterations: 75
State persistence: checkpoint after every 5 iterations

DETERMINED (50+ iterations, Opus)

Major initiatives with long time horizons
Examples: architecture overhauls, new product launches, company strategy
Model: Opus for all phases requiring strategic thinking
Max iterations: Infinite
State persistence: checkpoint after every iteration
Multi-agent collaboration enabled

The effort classification controls concrete system behavior—which AI model to use for each phase, how often to checkpoint state, when to enable multi-agent coordination.

Case Study 1: Bug Fix (QUICK - 4 iterations)

Let’s trace a concrete example: fixing a bug where API requests occasionally timeout.

Iteration 1:

OBSERVE: Review error logs, identify timeout pattern (occurs under load, p95 latency 8s, timeout set to 5s)

THINK: Root cause hypothesis: database query missing index, causing slow table scans under load

PLAN:

ISC 1: Identify slow queries in production logs
ISC 2: Add appropriate indexes
ISC 3: Verify p95 latency under 500ms
ISC 4: No timeouts in 1 hour of production traffic
Effort: QUICK (database optimization is straightforward)

BUILD: Write query to analyze slow query log, design index schema

EXECUTE: Run analysis against production logs

VERIFY: ISC 1 completed (found slow query on orders table), ISC 2-4 pending

LEARN: Query scans 2M rows for active users, created_at column not indexed

Iteration 2:

OBSERVE: Confirmed missing index on orders.created_at

THINK: Adding index will speed lookups but increase write cost (acceptable trade-off)

PLAN: Add compound index on (user_id, created_at), test in staging first

BUILD: Migration script with rollback procedure

EXECUTE: Run migration in staging

VERIFY: ISC 2 completed (index created), ISC 3-4 still pending

LEARN: Staging tests show 95% latency reduction (8s → 400ms)

Iteration 3:

OBSERVE: Staging performing well, no issues detected

THINK: Safe to deploy to production, monitoring critical

PLAN: Production migration during low-traffic window, 1-hour monitoring

BUILD: Deployment plan with rollback triggers

EXECUTE: Deploy index to production

VERIFY: ISC 3 completed (p95 latency 420ms), ISC 4 pending

LEARN: Immediate latency improvement observed

Iteration 4:

OBSERVE: 1 hour elapsed, monitoring data collected

THINK: No timeouts observed, latency stable

PLAN: Final verification

BUILD: Generate monitoring report

EXECUTE: Run verification queries

VERIFY: ISC 4 completed (0 timeouts in 1 hour, 2,847 successful requests)

LEARN: Index resolved the issue, document for future reference

Result: Task complete in 4 iterations. All ISC criteria met. Time elapsed: approximately 2 hours.

Case Study 2: Architecture (THOROUGH - 28 iterations)

Now let’s scale up: designing a new microservice for real-time event processing.

Iteration 1-5: OBSERVE & THINK

Early iterations focus on understanding requirements:

Event volume: 50k events/second peak
Latency requirement: p99 under 100ms
Availability: 99.99% uptime
Data retention: 30 days
Integration: existing Kafka cluster, PostgreSQL, Redis

Analysis surfaces constraints:

Existing services use REST, need to maintain compatibility
Compliance requires all events logged
Team familiar with Node.js, new tech creates learning overhead

Iteration 6-10: PLAN & BUILD

Define architecture:

Event consumer (Kafka → processing pipeline)
Processing engine (event validation, enrichment, routing)
State store (Redis for hot data, PostgreSQL for cold)
REST API (compatibility with existing services)
Monitoring (Prometheus, Grafana, distributed tracing)

ISC defined:

Handles 50k events/sec in load test
p99 latency under 100ms
99.99% uptime over 7-day test
All events persisted to PostgreSQL
Zero data loss during failover
REST API backward compatible
Full observability (metrics, logs, traces)

BUILD artifacts:

Architecture diagrams
API specifications (OpenAPI)
Data models
Infrastructure as Code (Terraform)
Deployment pipeline (CI/CD)

Iteration 11-20: EXECUTE & VERIFY (incremental)

Implement components incrementally:

Iteration 11-13: Kafka consumer with basic processing
Iteration 14-16: State management (Redis + PostgreSQL)
Iteration 17-18: REST API layer
Iteration 19-20: Monitoring and alerting

Each iteration verifies subset of ISC:

After Iteration 13: ISC 4 verified (events persisted)
After Iteration 16: ISC 2 partially verified (p99 at 120ms, needs optimization)
After Iteration 18: ISC 6 verified (REST API compatible)
After Iteration 20: ISC 7 verified (observability complete)

Iteration 21-25: Optimization

VERIFY reveals performance gaps:

ISC 1: Only handles 35k events/sec (need 50k)
ISC 2: p99 latency 120ms (need under 100ms)

THINK identifies bottlenecks:

Database writes blocking event loop
Serialization overhead in Kafka consumer

PLAN optimizations:

Batch database writes
Use binary serialization (Protocol Buffers)
Add consumer parallelism

EXECUTE changes, VERIFY improvements:

After Iteration 23: 48k events/sec, p99 95ms
After Iteration 25: 52k events/sec, p99 88ms
ISC 1 and 2 now met

Iteration 26-28: Final verification

Run extended tests:

7-day load test at production volume
Chaos engineering (simulate node failures)
Security audit

VERIFY remaining ISC:

ISC 3: 99.993% uptime achieved (exceeds 99.99% target)
ISC 5: Zero data loss during 10 simulated failovers

All ISC criteria met after 28 iterations. Time elapsed: 3 weeks.

Case Study 3: Company (DETERMINED - 200+ iterations)

The most ambitious scale: building a company from idea to launch. This is where the Universal Algorithm truly proves its universality.

Iterations 1-50: Problem Space (Months 1-2)

Early iterations operate at strategic level:

OBSERVE: Market research, customer interviews, competitive analysis

Healthcare providers spend $2B annually on scheduling software
40% report dissatisfaction with existing solutions
Key pain points: complex scheduling rules, poor mobile experience, limited integrations

THINK: Identify market opportunity and differentiation

Existing solutions built 10+ years ago, pre-mobile era
Modern tech stack enables better UX and performance
AI-powered scheduling optimization creates competitive moat

PLAN: Define MVP and go-to-market strategy

ISC for company (high-level):
1. Product launched with 5 paying customers
2. $50k MRR achieved
3. Monthly churn under 10%
4. Net Promoter Score above 50
5. Product-market fit validated (qualitative + quantitative)

BUILD: Business plan, financial model, pitch deck

EXECUTE: Fundraise, incorporate, hire founding team

VERIFY: $2M seed round raised, 3 engineers hired, legal entity formed

LEARN: Investor feedback surfaced concerns about sales strategy—needs refinement

Iterations 51-100: Product Development (Months 3-5)

Now we recurse into product-level planning. Each major feature becomes its own THOROUGH-level task with its own ISC and Ralph Loop.

The company-level Universal Algorithm spawns child algorithms:

Feature 1: Core scheduling engine (THOROUGH, 35 iterations)
Feature 2: Mobile application (THOROUGH, 42 iterations)
Feature 3: Integration platform (STANDARD, 18 iterations)

Each feature’s ISC rolls up to company ISC:

Feature 1 completion → enables ISC 1 (product launch)
Feature 2 completion → improves ISC 4 (NPS via mobile UX)
Feature 3 completion → enables ISC 2 (MRR via integration upsells)

Iterations 101-150: Go-to-Market (Months 6-8)

OBSERVE: Beta user feedback, usage analytics, support tickets

THINK: Initial users love mobile app, frustrated by integration limitations

PLAN: Prioritize integration expansion, defer advanced scheduling features

BUILD: 5 new integrations (EHR systems, payment processors)

EXECUTE: Sales outreach, onboarding new customers

VERIFY:

ISC 1: Launched with 8 paying customers (exceeded target of 5)
ISC 2: $28k MRR (need $50k)
ISC 3: 7% monthly churn (under 10% target)
ISC 4: NPS 62 (exceeded target of 50)
ISC 5: Product-market fit unclear—need more data

LEARN: Revenue below target but user satisfaction high—focus on customer acquisition, not product changes

Iterations 151-200: Scale (Months 9-12)

OBSERVE: Sales funnel metrics, CAC, LTV, expansion revenue

THINK: Current customers expanding usage, referrals strong—product works, need volume

PLAN: Invest in marketing, optimize sales process, build referral program

BUILD: Marketing campaigns, sales playbooks, referral incentives

EXECUTE: Launch campaigns, hire sales reps, implement referral system

VERIFY:

ISC 2: $54k MRR (exceeded $50k target)
ISC 5: Product-market fit validated (80% would be “very disappointed” without product)

Result: All company ISC criteria met after 200+ iterations spanning 12 months. Company successfully launched, product-market fit achieved, growth trajectory established.

The same algorithm that fixed a database index in 4 iterations built an entire company in 200+ iterations. The only difference: scope and persistence.

Memory System: Context Evolution Over Time

As tasks scale from QUICK to DETERMINED, context accumulates. The memory system manages this through a three-tier temperature model:

Hot Memory (Active Context)

Current iteration state
Recent decisions and their rationale
Active ISC criteria and verification results
Storage: Redis (fast access, 1-hour TTL)

Warm Memory (Session Context)

Last 10 iterations of learnings
Task history and decision log
Related task connections
Storage: PostgreSQL (persistent, indexed)

Cold Memory (Long-term Knowledge)

Completed task archives
Pattern libraries and reusable components
Strategic decisions and their outcomes
Storage: Vector database (semantic search enabled)

This three-tier system ensures:

Fast access to immediately relevant context (hot)
Learning continuity within a task session (warm)
Pattern reuse across similar tasks (cold)

Memory temperature automatically adjusts based on usage patterns. Frequently accessed warm memories get promoted to hot. Unused hot memories expire to warm. Cold memories are retrieved only via semantic similarity.

Hook System: Event-Driven Execution

The Universal Algorithm integrates with a hook system for event-driven middleware—enabling custom logic at every phase.

Hooks can be registered for:

Pre-phase hooks: Run before each phase executes (e.g., load domain knowledge before THINK)
Post-phase hooks: Run after each phase completes (e.g., update dashboard after OBSERVE)
Iteration hooks: Run before/after full iterations (e.g., checkpoint state)
Lifecycle hooks: Run at task start/completion (e.g., generate reports)

This enables powerful customizations without modifying core algorithm:

Compliance: Add approval gates before EXECUTE for production changes
Observability: Inject logging at every phase transition
Cost control: Check budget before expensive THINK operations
Integration: Notify external systems of progress
Domain logic: Load industry-specific knowledge before THINK

Hooks compose. You can stack multiple hooks per phase, each adding a layer of capability.

Implementation Guide

Ready to implement this framework? Here’s the practical path:

Level 1: Manual (Human-Driven)

Start by using the algorithm as a mental model. When facing any task:

OBSERVE: Write down current state explicitly
THINK: Document your analysis and root causes
PLAN: Define ISC criteria before starting work
BUILD: Create artifacts intentionally
EXECUTE: Take action deliberately
VERIFY: Check progress against ISC
LEARN: Document discoveries

This alone improves task clarity and reduces false completion.

Level 2: Semi-Automated (Tool-Assisted)

Introduce tooling to track ISC and iterations. Build a simple CLI or use task management software to:

Define tasks with explicit ISC criteria
Track iteration count and progress
Log learnings from each iteration
Visualize completion percentage

This gives you mechanical progress tracking and prevents premature completion.

Level 3: Fully Automated (Agent-Driven)

Build or integrate with an agent system that executes the algorithm autonomously. The agent handles routine execution while you focus on ISC definition and verification.

At this level, you’re orchestrating AI agents that follow the Universal Algorithm, freeing you to work at higher levels of abstraction.

The 15 PAI Principles

The Universal Algorithm is one component of PAI v2.1. The full system is guided by 15 principles that ensure consistency and quality:

Verifiability: All progress must be measurable via ISC
Composability: Tasks decompose into subtasks using same algorithm
Persistence: Context survives interruptions (Ralph Loop)
Efficiency: Match resource level to task complexity
Clarity: State must be explicit and observable
Adaptability: Learn from each iteration
Completeness: Continue until ISC satisfied, not until “good enough”
Hierarchy: Support tasks at all scales (TRIVIAL → DETERMINED)
Traceability: Maintain decision log for all phases
Separation: Distinguish BUILD from EXECUTE
Hooks: Enable extension without core modification
Memory: Manage context temperature (hot/warm/cold)
Models: Select appropriate AI model per phase/effort
Collaboration: Enable multi-agent coordination
Human-in-loop: Escalate blockers requiring judgment

These aren’t aspirational values—they’re implemented constraints that the system enforces.

What Makes This Universal

Three properties make this algorithm truly universal:

1. Scale Invariance

The algorithm works identically whether the task takes 30 seconds or 3 years. Only the ISC scope changes. Fixing a typo and building a company both follow:

OBSERVE → THINK → PLAN → BUILD → EXECUTE → VERIFY → LEARN

The number of iterations scales, but the structure remains constant.

2. Domain Independence

Nothing in the algorithm is specific to software. It applies equally to:

Writing code (OBSERVE: read codebase, THINK: identify architecture, PLAN: design solution…)
Writing essays (OBSERVE: research topic, THINK: organize arguments, PLAN: outline structure…)
Cooking recipes (OBSERVE: check ingredients, THINK: understand technique, PLAN: sequence steps…)
Running companies (OBSERVE: analyze market, THINK: identify opportunity, PLAN: strategy…)

The seven phases are fundamental to problem-solving itself.

3. Verifiable Termination

Unlike heuristic approaches (“keep working until it feels done”), ISC provides objective completion criteria. Tasks terminate when all criteria are met—not before, not after.

This eliminates both premature stopping (shipped before ISC met) and infinite iteration (working past completion).

Common Pitfalls and Solutions

After implementing this framework across 100+ tasks, patterns of failure emerged:

Pitfall 1: Vague ISC Criteria

Problem: “Make the API faster” is not verifiable.

Solution: Quantify everything. “p95 API latency under 500ms measured over 1000 requests” is verifiable.

Pitfall 2: Skipping OBSERVE

Problem: Jumping straight to solution without understanding current state.

Solution: Force explicit OBSERVE artifacts before allowing THINK. No measurement = no iteration.

Pitfall 3: BUILD/EXECUTE Confusion

Problem: Making production changes (EXECUTE) while still developing solution (BUILD).

Solution: Require explicit transition gate. BUILD produces artifacts, EXECUTE deploys them.

Pitfall 4: Insufficient Effort Classification

Problem: Using QUICK for complex architecture, running out of iterations before completion.

Solution: Conservative classification. When uncertain, choose higher effort level.

Pitfall 5: Ignoring LEARN

Problem: Iterations repeat mistakes because learnings not captured.

Solution: Make LEARN artifacts mandatory, reviewed before next OBSERVE.

Future Directions

Where does this framework evolve next?

Multi-Agent Orchestration

Currently, one agent executes one task. The next frontier: coordinating multiple agents on DETERMINED tasks.

Imagine building a product:

Agent A: Backend architecture (THOROUGH)
Agent B: Frontend development (THOROUGH)
Agent C: Infrastructure deployment (STANDARD)

Each agent runs its own Universal Algorithm instance. Coordination happens via:

Shared ISC (changes in one affect others)
Dependency tracking (Agent C blocked until Agent A completes)
Context sharing (Agent B learns from Agent A’s API design)

Reinforcement Learning on ISC

The ISC system generates training data: task description → plan → ISC → outcome. This enables learning:

Which ISC criteria predict success?
What effort classification minimizes iterations?
Which model selection strategy optimizes cost/quality?

Over time, the system learns to define better ISC from historical patterns.

Cross-Domain Pattern Transfer

As cold memory accumulates completed tasks, patterns emerge:

“Optimization tasks typically need 3-5 iterations”
“Database migrations require explicit rollback verification”
“API design benefits from prototyping in PLAN phase”

These patterns can transfer across domains. A performance optimization pattern from backend code might apply to database query optimization.

Conclusion

The Universal Algorithm isn’t a productivity hack or a time management technique. It’s a formalization of how effective problem-solving actually works, made explicit and verifiable.

Every task is a gap between current and ideal. Every gap closes through iteration. Every iteration follows the same seven phases. Progress is measured mechanically through ISC. Effort scales from TRIVIAL to DETERMINED. Models match task complexity. Memory preserves context. Hooks enable extension.

This framework has handled everything from fixing typos to designing distributed systems to building products. The algorithm didn’t change. Only the scope and persistence changed.

That’s what makes it universal.

The complete PAI v2.1 specification includes:

Detailed phase execution protocols
ISC template library
Model selection matrices
Hook system architecture
Memory management implementation
Multi-agent coordination patterns

If you’re building agent systems, managing complex projects, or just want better clarity on progress, the Universal Algorithm provides a concrete, verifiable framework.

What problems would you apply this to? What ISC criteria matter in your domain? I’d love to hear how others adapt this framework.

Jon Roosevelt is an AI architect building production agent systems. He specializes in making AI infrastructure practical, measurable, and reliable—turning conceptual frameworks into working systems that ship products.