We shipped MagiC v0.4 today. Two things worth talking about: embedded server mode and the benchmark suite we built to validate our performance claims.

Background: What is MagiC?

MagiC is an open-source framework for managing fleets of AI workers. Think Kubernetes for AI agents — it doesn’t build agents, it manages any agents built with any framework (CrewAI, LangChain, custom bots) through an open HTTP protocol.

         You (CEO)
          |
     MagiC Server  ←— Go, 15MB binary
    /    |    |    
ContentBot  SEOBot  LeadBot  CodeBot
(Python)   (Node)  (Python)  (Go)

The core is Go. Workers are anything that speaks HTTP.

What’s new in v0.4

1. Embedded server mode

Before v0.4, using MagiC from Python required you to separately install and run the Go server. Now you can do this:

from magic_ai_sdk import MagiC

with MagiC() as client:
    # Server is running. client is a MagiCClient.
    client.submit_task({"type": "summarize", "input": {"url": "..."}})
# Server stops automatically.

MagiC() downloads the correct binary for your platform on first use (Linux/macOS, amd64/arm64), caches it at ~/.magic/bin/, and starts it in the background. Second run is instant — no download.

This is how it works under the hood:

class MagiC:
    def __enter__(self) -> MagiCClient:
        binary = _get_binary(self._version)   # download if not cached
        self._proc = subprocess.Popen(
            [str(binary), "serve"],
            env={"MAGIC_PORT": str(self._port), **os.environ},
        )
        self._wait_ready()  # polls /health until 200 OK
        return MagiCClient(base_url=f"http://localhost:{self._port}")

    def __exit__(self, *_):
        self._proc.terminate()

The binary is pulled from GitHub Releases, which the release CI builds automatically for 4 targets on every v* tag:

- run: |
    GOOS=linux  GOARCH=amd64 go build -ldflags="-s -w" -o dist/magic-linux-amd64  ./cmd/magic
    GOOS=linux  GOARCH=arm64 go build -ldflags="-s -w" -o dist/magic-linux-arm64  ./cmd/magic
    GOOS=darwin GOARCH=amd64 go build -ldflags="-s -w" -o dist/magic-darwin-amd64 ./cmd/magic
    GOOS=darwin GOARCH=arm64 go build -ldflags="-s -w" -o dist/magic-darwin-arm64 ./cmd/magic

Result: pip install magic-ai-sdk is all a Python developer needs. No Go toolchain required.

2. Benchmark suite

A frequent question is: “Why Go? Won’t Python be fine?” We now have actual numbers.

The benchmark suite lives in core/benchmarks/ — 13 benchmarks covering routing, registration, heartbeat, and the event bus. Run them yourself:

git clone https://github.com/kienbui1995/magic
cd magic/core
go test -bench=. -benchtime=5s -benchmem ./benchmarks/...

Results on an i7-12700 (20 logical cores):

A few things worth noting:

Routing scales O(n) with worker count, which is expected — we scan all workers to filter by capability. With 1000 workers the overhead is 240µs. An LLM call is 1–30 seconds. The orchestrator is never the bottleneck.

Heartbeat at 1000 workers costs ~1ms per check cycle. In practice, heartbeats happen every 30 seconds per worker, so the server processes ~33 heartbeats/second at 1000 workers. Completely trivial.

The event bus at 26M events/second means no async communication between modules will ever be a bottleneck.

Why these numbers matter for fleet management

Every AI agent framework I’ve seen (AutoGen, CrewAI, Agno, LangGraph) runs agents as Python objects in a single process. There’s no heartbeat because there’s no persistent worker registry. There’s no routing because there’s no fleet.

Agno’s “529x faster” benchmark measures how quickly Python objects instantiate. That’s a valid metric for their architecture. MagiC measures something different: how many concurrent agents can the orchestrator manage, and how fast can it route tasks to them.

Python’s GIL means routing decisions for N concurrent agents share one thread. In Go, each heartbeat runs in its own goroutine (~2KB RAM, true parallelism). The numbers reflect that.

What’s coming in v0.5

We’re implementing zero-trust worker authentication:

• Each worker gets its own mct_<256-bit token> credential (not a shared API key)
• Token bound to a specific worker on first registration — can’t be reused or impersonated
• Org isolation: tasks from Org A can only route to workers in Org A
• Immutable audit log: every register/heartbeat/route/complete recorded

No competitor has this at the framework level. AutoGen agents have no identity. CrewAI’s shared_memory=True default has caused PII leaks between sessions. LangGraph gets closest with interrupt primitives but still no agent-level auth.

We’ll publish the implementation and a write-up when it ships.

Try it

pip install magic-ai-sdk

from magic_ai_sdk import MagiC, Worker, capability

# Define a worker
class SummarizerBot(Worker):
    @capability(name="summarize")
    def summarize(self, task):
        # your LLM call here
        return {"summary": "..."}

# Start server + register worker
with MagiC() as client:
    bot = SummarizerBot(name="SummarizerBot", endpoint="http://localhost:9001")
    bot.start(magic_url=client.base_url)

    result = client.submit_task({
        "type": "summarize",
        "routing": {"required_capabilities": ["summarize"]}
    })
    print(result)

GitHub: kienbui1995/magic

Feedback welcome — especially on the benchmark methodology. We want to publish fair comparisons, not marketing numbers.

Quick Comparison

gstack: The Startup Sprint

What it is: Garry Tan’s personal Claude Code setup, open-sourced. 15 opinionated workflow skills that turn Claude Code into a virtual engineering team — CEO, Designer, Eng Manager, Release Manager, Doc Engineer, QA.

The philosophy: AI agents work best when they follow the same sprint cadence that works for human teams. Think, Plan, Build, Review, Test, Ship, Reflect.

Strengths

Immediate productivity. Copy the skills, run the commands, ship code. gstack hit 23K stars in a week because it delivers instant value. No configuration ceremony — just /office-hours to think, /plan-ceo-review to plan, /ship to deploy.

Real-world provenance. This is how the president of Y Combinator actually builds software. It’s not theoretical — it’s battle-tested on real products.

Browser-first architecture. gstack runs a persistent Chromium daemon with sub-second latency. This is genuinely hard engineering — the browser doesn’t cold-start between commands, so QA testing and visual reviews are fast and stateful.

Cross-agent compatibility. Through the SKILL.md standard, gstack works with Claude Code, Codex, Gemini CLI, and Cursor.

Limitations

No governance layer. There’s no mechanism to prevent an agent from taking a harmful action. The workflow assumes good outcomes follow good process, which is true until it isn’t.

Copy-paste culture risk. 23K stars in a week means thousands of developers are running one person’s opinionated workflow without modification. gstack is Garry Tan’s brain — your team might need a different brain.

Solo-focused. The skills are designed for a single developer working with AI. There’s no multi-agent coordination, no conflict resolution, no audit trail for team accountability.

Superpowers: The Methodology

What it is: An agentic skills framework and software development methodology. More installs than Playwright on the Claude Code marketplace. 40K+ stars.

The philosophy: The bottleneck in AI-assisted development isn’t model capability — it’s methodology. If you teach agents disciplined engineering practices, they earn your trust.

Strengths

Trust through discipline. Superpowers enforces red-green-refactor TDD cycles where tests must fail before implementation. It requires root cause investigation before any fix. It runs Socratic brainstorming sessions that refine requirements before coding begins. This is genuine engineering methodology, not vibes.

Subagent-driven development. Once you approve the plan, Superpowers launches subagents to work through each task, inspecting and reviewing their work before continuing. The implementation plan is deliberately written for “an enthusiastic junior engineer with poor taste, no judgement, and an aversion to testing” — meaning the instructions are unambiguous enough for any agent to follow.

Compound learning. Each development cycle documents learnings for future AI agent consumption. 80% of developer time goes to planning and review, systematically creating a self-improving system.

Strong community. 40K+ stars and active development mean continuous improvement, community skills, and broad compatibility.

Limitations

Single-user scope. Like gstack, Superpowers is designed for a developer working with their AI agent. It doesn’t address multi-agent governance, cross-team coordination, or organizational-scale decision making.

No enforcement mechanism. The methodology is advisory — agents follow it because the prompts tell them to. There’s no rule engine that can BLOCK an action, no HALT that stops all processes, no human escalation gate that requires approval.

Methodology, not governance. Superpowers ensures agents build well. It doesn’t ensure they should build at all. There’s no red team challenging whether the decision itself was correct.

AEGIS: The Constitution

What it is: A governance-first framework where AI agents debate decisions in structured boardroom meetings, face mandatory red team review, and operate under constitutional rules with enforceable verdicts.

The philosophy: Every other multi-agent framework helps AI agents do things. AEGIS makes sure they should.

Strengths

Enforceable governance. AEGIS has a 5-verdict rule engine (PASS, FLAG, BLOCK, ESCALATE_TO_HUMAN, HALT) that prevents actions, not just advises against them. Self-review is blocked. Low-confidence decisions are flagged. Production deployments without review are escalated to humans.

from aegis_gov import RuleEngine

engine = RuleEngine()
# Production deploy without review? -> ESCALATE_TO_HUMAN
engine.evaluate("DevOps", "deploy", {
    "environment": "production",
    "tests_passed": True,
    "review_approved": False,
})

Mandatory red team. Every decision faces a DevilsAdvocate (challenges assumptions, demands evidence) and a Skeptic (explores alternatives, runs pre-mortem analysis). The red team cannot be disabled in the default configuration.

Structured decision-making. 17 AI agents with distinct roles debate every decision across 6 phases: CEO Opening, Executive Council (7 C-level perspectives), Advisory Input (8 specialists), Critical Review (red team), Open Debate, and CEO Synthesis with vote tally and confidence score.

Compliance-ready. The audit trail, decision categorization, and human escalation gates map directly to EU AI Act, NIST AI RMF, and ISO 42001 requirements.

LLM-agnostic. Works with Anthropic, OpenAI, or any OpenAI-compatible API (including local models via Ollama).

Limitations

Overhead for small projects. If you’re a solo developer building a side project, a 17-agent boardroom meeting is overkill. gstack or Superpowers will get you shipping faster.

Newer project. AEGIS doesn’t have 40K stars (yet). The community is smaller, and the ecosystem is younger.

Governance adds latency. A full boardroom meeting with red team review takes time. For rapid prototyping, you want speed. For production decisions with real consequences, you want governance.

When to Use Which

The Combination Play

These tools are not mutually exclusive. The strongest setup might be:

• gstack for your sprint workflow (Think, Plan, Build)
• Superpowers for your engineering methodology (TDD, debugging, brainstorming)
• AEGIS as the governance layer on top (Can we? Should we? Who approves?)

AEGIS is explicitly designed to be “the governance layer you add on top” of existing frameworks.

Try AEGIS

pip install aegis-gov
aegis convene "Should we mass-email all users about the new feature?" --category TACTICAL

• GitHub: github.com/pyonkichi369/aegis-oss
• PyPI: pypi.org/project/aegis-gov
• License: Apache 2.0

Want the full 140-agent configuration with 148 optimized prompts? The AI Agent Prompts Pack includes production-ready agent definitions, constitutional governance templates, and the complete AEGIS organizational structure.

What’s your approach to AI agent governance? Are you in the “trust the workflow” camp, the “enforce methodology” camp, or the “constitutional governance” camp? Drop a comment below.

You describe how it feels. It draws what it looks like.

There’s a question I’ve been sitting with for a while:

What does a song look like?

Not the album art. Not the waveform. The feeling of it. The way Gymnopédie No.1 feels like fog over cold water. The way Bohemian Rhapsody feels like architecture that shouldn’t work but does.

Spotify tried to answer this with their audio features API — energy, valence, danceability, tempo. Machine-derived floats between 0 and 1. They deprecated it last year.

I think they were solving the wrong problem anyway.

Your ears are the API

Spotify’s audio analysis is about the signal. I’m interested in the experience.

So I built Song Portrait — a tool where you are the data source.

You describe a song across 8 perceptual dimensions:

• Energy — soft and still, or electric and alive?
• Mood — sitting in shadows, or reaching for light?
• Tempo Feel — floating, or driven?
• Texture — smooth like glass, or rough like gravel?
• Warmth — cold and distant, or warm and close?
• Complexity — a single thread, or layered and intricate?
• Space — intimate, like you’re in the room, or vast, like standing outside at night?
• Memory — something new, or something that pulls at decades?

Move the sliders. The portrait draws itself.

What it draws

Each set of values generates a spiral DNA structure — a pair of intertwining helices whose properties are all derived from what you felt:

• Number of strands: driven by Complexity (2–6)
• Number of turns: driven by Tempo Feel (floaty vs. driven)
• Radius and bloom: driven by Space and Energy
• Color palette: driven by Warmth and Mood
• Noise and distortion: driven by Texture
• Rung density (the cross-links between strands): driven by Complexity
• Vertical tilt: driven by Mood (sad songs droop, bright songs lift)
• Film grain overlay: driven by Memory — nostalgic songs get a grainy fog

The result is different for every song. And every person’s description of the same song.

Two people. Same song. Different portraits.

That’s the part I find most interesting.

If you and I both describe “Black” by Pearl Jam, we might both agree it’s low-energy, very dark, heavy on memory. But you might feel more complexity in the guitar work; I might feel more space in the production. Our portraits will be similar but not identical.

The portrait isn’t a fact. It’s a record of how you heard it.

That feels more honest than a database entry.

Try the presets

I built in six presets to get you started:

Each portrait is animated — the helix rotates slowly, driven by Tempo Feel. You can download any frame as a PNG.

Why I built this

I’ve been building a series of tools I call “useless but beautiful” — things that don’t help you do anything, but reveal something.

Noise Field makes particle art from invisible forces. Breathing Clock encodes the time into organic forms. Code Scent translates your codebase into landscape.

Song Portrait continues that logic: take something invisible — the subjective experience of music — and give it a visible form.

I don’t know if the portraits are “accurate.” I’m not sure accuracy is the right standard for something that lives in the gap between sound and feeling.

What I do know: when I loaded the Satie preset and saw thin blue-grey spirals drifting in cold space, it felt right.

Open Song Portrait →

Free. No account. Runs entirely in your browser.

If you describe a song and like how it looks, I’d genuinely want to see it — reply here or find me @Clavis_Citriac.