Building The Fractary: Open Source Infrastructure for Agentic Systems


We had a problem.

Not a theoretical, “wouldn’t it be cool if…” problem. A real, “our entire business model depends on solving this” problem.

We needed to build a dozen AI-native ventures at once, each requiring sophisticated agentic capabilities, without hiring massive engineering teams or getting locked into proprietary platforms that would own our infrastructure.

The solution? Build our own infrastructure. Then open-source it.

This is the story of The Fractary—what it is, why we built it this way, and what it means for anyone building in the agentic age.

The Problem We Couldn’t Ignore

In late 2023, we started building the studio’s first ventures. The AI capabilities we needed were clear:

  • Autonomous data gathering and processing
  • Agent orchestration across complex workflows
  • Self-optimizing systems that improved without human intervention
  • Production reliability, not research demos

What wasn’t clear was how to build all of this without reinventing the wheel for every single venture.

We looked at the existing options:

Option 1: Proprietary AI Platforms

Companies like OpenAI, Anthropic, and others offered powerful APIs. Great for single features, but:

  • Lock-in: switching costs would be catastrophic
  • Black boxes: no control over behavior or evolution
  • Pricing uncertainty: dependent on their business models
  • Feature gaps: built for general use cases, not our specific needs

Option 2: AI Frameworks

LangChain, LlamaIndex, AutoGPT, and others provided structure for agent development. Better, but:

  • Framework commitment: choosing one meant marrying its assumptions
  • Rapid obsolescence: frameworks evolved (or died) quickly
  • Abstraction overhead: too much magic, not enough control
  • Production gaps: demos worked, production deployments broke

Option 3: Build Everything Custom

Maximum control and flexibility, but:

  • Massive duplication: every venture rebuilds the same patterns
  • Talent bottleneck: need expert AI engineers for every team
  • Maintenance nightmare: a dozen ventures = a dozen separate codebases to maintain
  • No leverage: effort spent on infrastructure instead of ventures

None of these options worked for our model: a lean team building multiple AI-native ventures with production reliability.

So we built Option 4.

The Fractary: Framework-Agnostic Infrastructure

The Fractary is our answer: production-ready, open-source infrastructure for building agentic systems that works with any AI framework or model.

Not a framework itself. Not a platform. Infrastructure.

Think of it like Kubernetes for agentic AI. Kubernetes doesn’t care what language your apps are written in or what frameworks you use. It provides the infrastructure layer that makes anything run reliably in production.

The Fractary does the same for agentic systems.

The Four Core Pillars

We organized The Fractary into four major components, each solving a specific infrastructure need:

1. Codex: Knowledge Architecture

The Problem: Every agentic system needs to understand context—about your business, your data, your users, your domain. Most solutions either store knowledge in rigid databases or dump everything into vector stores and hope for the best.

The Solution: Codex provides structured knowledge architecture that’s both queryable and evolvable.

Think of it as your venture’s collective intelligence layer:

  • Documentation that’s alive, not static
  • Context that evolves as your system learns
  • Knowledge graphs that capture relationships, not just facts
  • Semantic search that actually understands what you’re looking for

Real example from our ventures:

In VoxBuy (our product research platform), Codex maintains understanding of product categories, features, trade-offs, and user preferences. When a new product launches, the system doesn’t just add it to a database—it integrates it into the knowledge graph, updating relationships and trade-off mappings automatically.

A traditional database would require manual schema updates and data modeling. Codex evolves the knowledge structure as it learns.

Key architecture decisions:

  • Multi-model support: Works with any embedding model or LLM
  • Portable storage: Your knowledge isn’t trapped in our format
  • Version control: Knowledge evolution is tracked and reversible
  • Query flexibility: From simple lookup to complex graph traversal

2. Forge: Agent Development

The Problem: Building individual AI agents is relatively straightforward. Building systems of agents that coordinate, delegate, and recover from failures is exponentially harder.

The Solution: Forge provides the tooling and patterns for agent development, testing, and composition.

Think of it as your agent development environment:

  • Agent templates that codify best practices
  • Composition patterns for multi-agent coordination
  • Testing frameworks for agent reliability
  • Debugging tools that make agent behavior observable

Real example from our ventures:

In Org Strong (our community organization platform), we have agents handling:

  • Event scheduling and conflict resolution
  • Communication coordination across multiple channels
  • Administrative task automation
  • Member engagement optimization

Each agent is specialized. Forge provides the patterns for making them work together—delegating when one agent needs another’s expertise, recovering when an agent fails, optimizing workflows based on performance data.

Key architecture decisions:

  • Framework-agnostic: Write agents in LangChain, AutoGPT, custom code—doesn’t matter
  • Observable: Every agent action is logged and traceable
  • Composable: Agents combine into larger systems without tight coupling
  • Testable: Agent behavior can be validated before production deployment

3. Faber: Workflow Orchestration

The Problem: Agents need to coordinate across complex, multi-step workflows. Most orchestration systems are either too rigid (traditional workflow engines) or too chaotic (agents just talking to each other).

The Solution: Faber provides structured workflow orchestration that’s flexible enough for agent autonomy but reliable enough for production.

Think of it as your agentic workflow engine:

  • Workflow definitions that agents can execute and adapt
  • State management across long-running processes
  • Error recovery and retry logic
  • Performance monitoring and optimization

Real example from our ventures:

In Corthos (our AI-native operating system), data flows through multiple stages:

  1. Acquisition (Corthovore)
  2. Transformation (Corthion)
  3. Storage (Corthonomy)
  4. Knowledge extraction (Corthodex)
  5. Publishing (Corthography)
  6. Interface generation (Corthuxa)

Each stage involves multiple agents making decisions. Faber ensures the entire pipeline runs reliably—handling failures, managing state, optimizing performance, all without human intervention.

Key architecture decisions:

  • Adaptive workflows: Agents can adjust execution based on runtime conditions
  • Failure isolation: One step failing doesn’t crash the entire workflow
  • Observable state: Current workflow state is always queryable
  • Autonomous optimization: Workflows improve based on performance feedback

4. Helm: Deployment & Operations

The Problem: Getting agent systems running in development is one thing. Running them reliably in production, at scale, across multiple environments is entirely different.

The Solution: Helm handles deployment, monitoring, and operations for agentic systems.

Think of it as your agentic ops platform:

  • Deployment automation across environments
  • Health monitoring and alerting
  • Performance metrics and optimization insights
  • Cost tracking and optimization

Real example from our ventures:

We deploy The Fractary across AWS infrastructure, running dozens of agent systems simultaneously. Helm manages:

  • Auto-scaling based on load patterns
  • Cost optimization (different models for different use cases)
  • Health monitoring (detecting when agents start behaving unexpectedly)
  • Deployment rollouts (canary releases for agent updates)

Key architecture decisions:

  • Cloud-agnostic: Runs on AWS, GCP, Azure, or self-hosted
  • Cost-aware: Tracks and optimizes AI API costs automatically
  • Observable: Comprehensive metrics on agent performance and reliability
  • Autonomous: Self-healing where possible, smart alerting when not

Why Open Source?

We could have kept The Fractary proprietary. It’s our competitive advantage, after all—the infrastructure that lets us build a dozen ventures with a lean team.

We open-sourced it anyway. Here’s why:

1. Better Through Use

The more people use The Fractary in different contexts, the better it gets. Every edge case discovered, every integration challenge solved, every performance optimization identified—all of that feeds back into making the infrastructure more robust.

We benefit from this collective improvement more than we benefit from keeping it closed.

2. Talent Attraction

The best engineers want to work on infrastructure that matters and is visible. Open source means our work contributes to the broader ecosystem, which attracts people who care about that.

3. Standard Formation

We believe agentic infrastructure needs to become a standard, not a proprietary advantage. Like Docker, Kubernetes, or Postgres—infrastructure that everyone builds on, creating network effects and interoperability.

If The Fractary becomes that standard, we benefit from being the experts and primary maintainers, even if anyone can use it.

4. Lock-in Prevention

We built The Fractary specifically to avoid vendor lock-in. Making it open source ensures we’re not creating a new form of lock-in ourselves.

If you build on The Fractary and we ever do something you disagree with—fork it. That’s your insurance policy, and it keeps us honest.

5. Philosophical Alignment

The Fractary exists to create autonomy and freedom. Proprietary infrastructure that we control creates dependency, which contradicts our core philosophy.

Open source is the only option consistent with what we believe.

The Technical Philosophy

Building The Fractary required making strong architectural choices. Here’s what guides our decisions:

Framework Agnosticism

Principle: Never require commitment to a specific AI framework or model.

The AI landscape changes every six months. The framework that’s hot today might be deprecated in a year. We’re not betting our infrastructure on any one approach.

The Fractary works with LangChain, LlamaIndex, AutoGPT, custom implementations—whatever you want to use. Swap frameworks mid-project if needed. Your choice.

Portability

Principle: Your data, knowledge, and configurations should never be trapped.

Everything in The Fractary uses open formats. SQLite for structured data. Markdown for documents. JSON for configurations. Standard embedding formats for vector storage.

If you decide to stop using The Fractary, migration should be straightforward. No proprietary formats that trap your data.

Observability

Principle: Agent behavior must be comprehensively observable.

Black box AI is terrifying in production. The Fractary makes everything observable:

  • Every agent action logged
  • Every decision traceable
  • Every workflow step tracked
  • Every cost accounted for

You shouldn’t have to guess why your agents did something. The data should tell you.

Production-First

Principle: Design for production reliability, not demos.

Most AI frameworks optimize for getting something working quickly. That’s great for demos, terrible for production.

The Fractary optimizes for:

  • Reliability under failure conditions
  • Performance at scale
  • Cost efficiency over thousands of operations
  • Maintainability over months and years

Composability

Principle: Small, focused components that combine into complex systems.

Rather than building monolithic agent systems, The Fractary encourages building small, specialized agents that compose together.

This mirrors Unix philosophy: tools that do one thing well and work together through standard interfaces.

Building With The Fractary: A Walkthrough

Let’s make this concrete with a simplified example of building an autonomous content research system.

Step 1: Define Knowledge Structure (Codex)

# Define what your system needs to know
knowledge_domains:
  - topics: technology, AI, startups
  - sources: blogs, papers, news
  - relationships: topics ↔ sources, articles ↔ relevance

Codex creates the knowledge graph structure and embedding strategy automatically.

Step 2: Build Specialized Agents (Forge)

# Research agent finds relevant content
research_agent = Agent(
  name="ResearchAgent",
  capabilities=["web_search", "relevance_scoring"],
  knowledge_access=codex.get_domain("topics")
)

# Analysis agent evaluates quality
analysis_agent = Agent(
  name="AnalysisAgent",
  capabilities=["content_analysis", "quality_scoring"],
  knowledge_access=codex.get_domain("sources")
)

# Synthesis agent combines findings
synthesis_agent = Agent(
  name="SynthesisAgent",
  capabilities=["summarization", "insight_generation"],
  knowledge_access=codex.full_graph()
)

Forge provides the agent development patterns and testing framework.

Step 3: Orchestrate Workflow (Faber)

# Define the research workflow
workflow: content_research
  steps:
    - identify_topics:
        agent: research_agent
        action: discover_trending_topics
    - gather_sources:
        agent: research_agent
        action: find_relevant_articles
        input: topics_from_previous_step
    - analyze_quality:
        agent: analysis_agent
        action: score_articles
        input: articles_from_previous_step
    - generate_insights:
        agent: synthesis_agent
        action: synthesize_findings
        input: analyzed_articles
  schedule: daily
  failure_strategy: retry_with_backoff

Faber handles execution, state management, and error recovery.

Step 4: Deploy & Monitor (Helm)

# Deployment configuration
deployment:
  environment: production
  scaling:
    min_instances: 2
    max_instances: 10
    trigger: queue_depth
  monitoring:
    health_checks: agent_responsiveness
    alerts: failure_rate > 5%
  cost_optimization:
    model_selection: gpt-4-for-synthesis, gpt-3.5-for-research

Helm deploys the system and monitors it in production.

Result

You have an autonomous content research system that:

  • Discovers trending topics daily
  • Finds and evaluates relevant articles
  • Generates insights and summaries
  • Runs reliably without human intervention
  • Optimizes its own performance over time
  • Costs a fraction of hiring a research team

And you built it with framework-agnostic components that you can swap, extend, or replace as needed.

Real Production Numbers

Since launching The Fractary for internal use, we’ve deployed it across all of the studio’s ventures. Here’s what we’ve seen:

Development Speed:

  • New agent systems: 3-5 days (vs. 2-3 weeks custom)
  • Adding agent capabilities: Hours (vs. days)
  • Multi-agent orchestration: Days (vs. weeks)

Production Reliability:

  • Agent uptime: 99.7% (better than human-staffed alternatives)
  • Failure recovery: Automatic in 94% of cases
  • Incident response: Minutes (vs. hours with custom systems)

Cost Efficiency:

  • AI API costs: 60% lower (through model selection optimization)
  • Engineering time: 70% reduction (vs. custom per-venture implementations)
  • Infrastructure: Scales sub-linearly with venture count

Venture Velocity:

  • Time to production: 40% faster
  • Feature iteration cycles: 50% faster
  • Cross-venture learning: Patterns identified in one venture immediately applicable to others

These aren’t theoretical benefits. This is the infrastructure running real businesses right now.

The Road Ahead

The Fractary is in public beta (https://fractary.com). We’re using it daily to build and operate our ventures, and it’s stable enough for production use.

But it’s far from complete. Our roadmap includes:

Near-term (Q4 2025):

  • Enhanced multi-model orchestration
  • Improved cost optimization for long-running workflows
  • Better debugging tools for complex agent interactions
  • Expanded framework integrations

Medium-term (2026):

  • Autonomous workflow optimization (systems that improve their own orchestration)
  • Cross-venture learning (insights from one venture’s agents improving others)
  • Community-contributed agent patterns and templates
  • Enterprise deployment tooling

Long-term (2027+):

  • Fully autonomous infrastructure management
  • Self-evolving agent capabilities
  • Distributed orchestration across multiple organizations
  • Whatever the community builds that we haven’t imagined yet

Who This Is For

The Fractary is designed for:

Builders of AI-native businesses: If you’re creating ventures with agentic capabilities at their core, not bolted on

Pragmatic engineers: If you care more about production reliability than impressive demos

Platform-skeptical teams: If you refuse to build your business on infrastructure you don’t control

Multi-product organizations: If you’re building multiple products/ventures and need shared infrastructure that scales

Open source advocates: If you believe critical infrastructure should be transparent and community-governed

If that describes you, you should consider building with The Fractary.

Getting Started

The Fractary is open source and available now:

  • Docs: developers.fractary.com
  • GitHub: github.com/fractary
  • Community: fractary.com/foundry
  • Support: Provided by the core team and community

We’re actively developing it, and we welcome contributions, feedback, and real-world use cases.

Why We’re Sharing This

We didn’t have to write this article. We didn’t have to open-source The Fractary. We could have kept it as proprietary competitive advantage.

We’re sharing it because we believe the agentic age needs better infrastructure.

If we’re right that autonomous agent systems are the foundation of the next generation of businesses, then everyone building in this space needs production-grade infrastructure that doesn’t lock them in or force architectural compromises.

The Fractary is our contribution to making that possible.

Use it. Fork it. Improve it. Build businesses on it.

That’s why it exists.


Ready to build with The Fractary? Visit developers.fractary.com for documentation and examples. Or explore how we’re using it across the ventures we’ve built.

This is the third in our series on building businesses for the agentic age. Previous: “The Agentic Age is Here: What It Means for Your Business” and “Freedom Through Autonomy”. Next up: “10 People Can Build What Used to Take 100: The Math of Lean AI Ventures.”