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

A lawyer-turned-developer open-sourced OpenSymphony, an AI agent framework that enforces personality, governance, and self-evolution through YAML-based souls, a multi-layer governance system, and a tool workshop. The framework, available on PyPI under MIT license, aims to solve agent safety and identity persistence problems that existing orchestration frameworks neglect.

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 https://github.com/lawcontinue/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. You've used LangChain agents. They're good at calling tools in sequence. They're bad at: OpenSymphony addresses these with three architectural pillars: Soul, Governance, and Self-evolution. 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. 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. python 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. 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. 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. Agents need memory that works at different timescales: | Tier | Storage | Purpose | |---|---|---| | L1 | In-memory | Current conversation context | | L2 | SQLite | Experience database with full-text search | | L3 | Cloud API | Long-term persistent memory | 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. 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. 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 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. python 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" 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. The framework is MIT-licensed and on GitHub https://github.com/lawcontinue/opensymphony . 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.