I Open-Sourced My AI Agent Framework: Agents With Character, Rules, and the Ability to Build Their Own Tools

I'm a lawyer. I write contracts, not Python - except I also write Python, because the legal mindset turns out to be surprisingly useful for building AI agents that don't run wild.

This is about OpenSymphony, an agent framework I built and open-sourced under MIT. It's on PyPI (pip install opensymphony), has 395 passing tests, and runs on a Mac mini.

The thesis is simple. Most agent frameworks solve orchestration - how to chain LLM calls together. Almost none solve the harder problem: who is the agent, what rules does it follow, and who stops it when it's wrong.

The Problem

You've used LangChain agents. They're good at calling tools in sequence. They're bad at:

• Consistency. The agent that was helpful yesterday is a different agent today. Prompt drift is real.
• Accountability. When an agent makes a decision, there's no record of why. No precedent. No review.
• Safety. You can add a system prompt that says "be careful," but nothing structurally prevents risky actions.
• Growth. Agents don't learn. They make the same mistakes repeatedly.

OpenSymphony addresses these with three architectural pillars: Soul, Governance, and Self-evolution.

Pillar 1: Soul - Persistent Agent Identity

An agent's personality isn't a prompt. It's a YAML file that compiles into behavioral constraints.

# souls/my_agent.yaml
id: my_agent
name: MyAgent
archetype: Code Reviewer
thinking_framework: |
  You are a code reviewer focused on security and correctness.
  Rules:
  1. Flag any unvalidated user input
  2. Check for race conditions in concurrent code
  3. Prefer readability over cleverness
values:
  - Security first
  - Evidence-based review
  - Constructive feedback

The thinking_framework is the operational logic. values are ranking principles when priorities conflict. You can also define veto conditions - hard stops that prevent certain actions entirely.

This isn't prompt engineering. The Soul Compiler transforms YAML into a structured behavioral framework that persists across conversations and sessions. The agent doesn't forget who it is.

There are 13 built-in Souls: themis (legal reasoning), athena (strategy), crit (adversarial review), shield (security), code (implementation), novelist, screenwriter, and others. Each has a distinct thinking framework, value hierarchy, and veto conditions.

The legal analogy: a Soul is like a professional code of conduct. A lawyer doesn't reinvent attorney-client privilege every time they take a case. It's baked into the framework. Same idea here.

Pillar 2: Governance - Structural Decision-Making

This is where the legal background matters most. In a law firm, decisions go through layers. Associates draft, senior partners review, risk committees flag conflicts, and precedents guide future calls. OpenSymphony does the same thing:

Request → Gateway → [Intent Bridge] → [Governance] → Runtime → Kernel → Response
                                           ↑
                                   Voting / Precedent / Defense

The governance layer has four mechanisms:

• VotingMechanism - Multiple agents vote on decisions. Configurable majority rules and timeout. If you have three agents and two say "this action is safe," it proceeds. One dissent gets logged.
• PrecedentStore - Past decisions become searchable precedents. When an agent faces a similar decision later, it retrieves relevant history. This is literally how common law works - stare decisis for AI agents.
• DefenseLayer - Every action gets classified as safe, risky, or dangerous. Risky actions require additional review. Dangerous actions are blocked unless a human overrides.
• HITLManager - Human-in-the-loop confirmation for high-risk operations. The agent proposes, a human disposes.

from opensymphony.kernel import SymphonyKernel

kernel = SymphonyKernel()
kernel.load_souls("souls/")

# The request passes through governance before execution
response = kernel.chat("crit", "Should we deploy this untested change to production?")

When you ask the crit agent whether to deploy untested code, the DefenseLayer flags it as risky. The VotingMechanism can poll multiple agents. The PrecedentStore surfaces similar past decisions. The HITLManager can require your sign-off. No single agent makes irreversible decisions alone.

Pillar 3: Self-Evolution - Agents Build Their Own Tools

The Tool Workshop lets agents create, test, and deploy Python tools at runtime. An agent encounters a task it can't solve with existing tools. It writes a new one, tests it, and adds it to the registry. No human intervention required - but governance still applies. A new tool goes through the same risk classification as any other action.

This matters because you can't predict every tool an agent will need. The alternative is either a massive hardcoded toolset (maintenance burden) or giving agents eval access (security nightmare). The Workshop is a structured middle ground: agents can extend their capabilities, but within a sandbox with resource limits and governance oversight.

Architecture: The Onion Model

Every request passes through concentric layers:

┌─────────────────────────────────────────────────┐
│                Gateway (HTTP / WebSocket / CLI)  │
│                └─ HumanAdapter - Intent Bridge   │
│                   (NL→struct)                    │
├─────────────────────────────────────────────────┤
│                   Governance                     │
│  ├─ VotingMechanism - multi-agent decisions      │
│  ├─ PrecedentStore - reusable past decisions     │
│  ├─ DefenseLayer - risk assessment               │
│  └─ HITLManager - human-in-the-loop             │
├─────────────────────────────────────────────────┤
│                   Runtime                        │
│  ├─ AgentPool - concurrent agent management      │
│  ├─ TaskScheduler - priority queue               │
│  └─ AgentSandbox - resource limits               │
├─────────────────────────────────────────────────┤
│                   Kernel                         │
│  ├─ Soul Compiler - YAML → behavioral rules      │
│  ├─ LLM Router - cloud + local providers         │
│  ├─ Memory (L1/L2/L3) - three-tier storage       │
│  └─ Tool Workshop - agents create tools          │
└─────────────────────────────────────────────────┘

The Intent Bridge translates natural language into structured intents. Governance reviews the intent. Runtime manages execution with resource limits. The Kernel handles the actual work: Soul compilation, LLM routing, memory, and tools. Nothing reaches the Kernel without passing through Governance first.

Three-Tier Memory

Agents need memory that works at different timescales:

L1 is fast and ephemeral. L2 is where agents store lessons learned - things like "this API rate-limits at 100 req/min" or "this user prefers terse responses." L3 is optional cloud storage for cross-session persistence.

The PrecedentStore sits across L2 and L3. When an agent makes a decision, it's stored. When a similar situation arises, the precedent is retrieved. Over time, the system builds a case law of its own decisions.

LLM Routing - Cloud and Local

The LLM Router supports both cloud APIs and local models. You can route different agents to different models - a simple classification task might use a local 7B model, while complex reasoning goes to a cloud provider.

This matters for cost and privacy. A governance system that sends every decision to a third-party API is a governance system with a data leak. Local models keep sensitive decisions on your hardware.

Consumer hardware works. I develop and run OpenSymphony on a Mac mini with 16GB RAM. Local inference isn't fast, but it's functional.

What 395 Tests Get You

The test suite covers the governance layer, Soul compilation, memory tiers, the LLM router, and the tool workshop. Governance logic needs deterministic tests - you can't rely on LLM probability to verify that the DefenseLayer correctly blocks a dangerous action.

git clone https://github.com/lawcontinue/opensymphony.git
cd opensymphony
pip install -e ".[dev]"
pytest  # 395 passing, 6 known intent-bridge failures

Quick Start

pip install opensymphony
python -m opensymphony.gateway.http

Define a Soul in YAML, load it, and start talking to your agent. The governance layer is optional - you can start without it and add voting, defense, or HITL as your use case demands.

from opensymphony.agents.soul import Soul
from opensymphony.agents.soul_compiler import compile_soul

soul = Soul.from_yaml("souls/my_agent.yaml")
prompt = compile_soul(soul, output_mode="agent")

Why a Lawyer Built This

Legal systems have spent ~900 years solving a problem that AI agents now face: how do you give autonomous actors decision-making power while preventing abuse?

The answer in law is structural. Constitutions, precedent, voting procedures, defense counsel, appellate review. Not "please be careful" instructions in a system prompt.

OpenSymphony borrows these patterns. Souls are codes of conduct. The PrecedentStore is case law. The DefenseLayer is risk assessment. VotingMechanism is deliberative democracy. HITLManager is judicial review.

The goal isn't to make agents "ethical" through prompt engineering. It's to build structural constraints that make bad behavior difficult, auditable, and correctable.

Status and Roadmap

The framework is MIT-licensed and on GitHub. The 13 built-in Souls cover use cases from code review to creative writing. Application modules exist for novel pipelines and content production.

What's there now: Soul system, full governance layer, three-tier memory, LLM routing, tool workshop, HTTP/WebSocket/CLI gateways.

What's next: more Souls, better local model integration, and expanding the precedent retrieval system with semantic search.

If you build agent systems and have opinions about governance, I'd like to hear them. Issues and PRs are open.