DEV Community: Harry Hu

Compromise my agent runtime and you still can't reach my database

Harry Hu — Mon, 24 Aug 2026 10:27:13 +0000

Most self-hosted AI platforms run everything in one service. The agent executes, the control plane decides, the database sits right there. One prompt injection that escapes into the runtime, and the attacker is one hop from your Postgres.

I didn't want to ship that. So Parthenon is three services that are deliberately not allowed to talk to everything:

Control Center — the brain. IAM, governance, the Role → SOP → Skill → Tool permission chain. It's the only service with a database connection.

Agent Runtime — the hands. Executes agent code. Stateless, disposable, and it has no database connection at all. It reaches the Control Center through a narrow, authenticated API, and nothing else.

Communication Hub — the nerves. Message routing and notifications between services, so the runtime never needs to know where anything lives.

The payoff is blast radius. The Agent Runtime is the service most likely to get compromised — it runs untrusted tool calls by definition. But when it is, there's nothing there to steal: no database credentials, no IAM state, no history. The worst case is a contained mess, not a breach.

Two things made this actually work in practice:

1. Dual identity. Agents and humans live in separate Keycloak realms with separate OIDC clients. An agent's token can never be mistaken for a human's, and vice versa. Every action in the audit trail is attributable — "which agent did this" is always answerable. That's what makes human-in-the-loop reviewable instead of performative.

2. Observability by default. OpenTelemetry traces, metrics, and logs out of the box. When an agent misbehaves you can see the full call chain, not just the final error.

It's not free. Three services means real orchestration overhead: startup order matters (the runtime and hub need the Control Center up first to bootstrap certificates), and a distributed system is always harder to debug than a monolith. For a solo dev or small team that's a genuine cost. I think it's worth it when the alternative is your database sitting one hop from arbitrary agent code.

The service boundaries, the IAM model, the migration discipline — none of it was accidental. It was spec'd feature by feature through easyspec, a spec-driven dev kit that runs a gated chain of AI agents through a propose → apply → update-master pipeline. The architecture is the output of that process.

Parthenon repo: https://github.com/hurungang/parthenon
easyspec repo: https://github.com/hurungang/easyspec
59-min feature walkthrough: https://youtu.be/uW4r8Ygj15Y

A Spec-Driven Dev Kit That Orchestrates 7 AI Agents — Built a 220k-Line Platform for Under $100

Harry Hu — Wed, 19 Aug 2026 07:03:08 +0000

Two weeks ago I launched Parthenon and told everyone an AI agent was bossing me around. What I never explained properly was the tool that actually built the thing.

That tool is easyspec — and it deserves its own post, because it's arguably the more interesting of the two.

Built on OpenSpec, pushed further

First, the honest credit: easyspec is based on OpenSpec. The spec format, the change lifecycle, and the agent-delegation model all trace back to their ideas — I didn't invent spec-driven development, I built on top of it. If OpenSpec resonates with you, you'll recognize the bones.

But I pushed it in a few directions that turned out to matter a lot:

1. An enriched spec that maps to source code. A spec that just says "build a dashboard" is a nice essay but useless context for an AI agent. easyspec specs include a source-code map — the files, modules, and entry points a change touches. That's context engineering: each agent loads exactly the right slice of the codebase instead of drowning in all of it.

2. A team of sub-agents, each owning one stage. One agent doing everything drifts. easyspec splits the lifecycle across seven specialized agents:

Agent	Owns
Product Owner	the change proposal + acceptance criteria
UX Specialist	the interactive prototype
Architect	system + data-model design
Database Designer	the schema
Developer	implementation
Tester	tests + execution
Document Reviewer	"no implementation detail in docs"

3. Inter-agent review and sign-off. No output is trusted on faith. Each stage is gated: the architect reviews the spec before design proceeds, the developer can't apply until architecture is signed off, and the master spec only moves when the tester passes the suite. es-master-review runs the full test suite and requires a clean status before update-master. No silent drift.

4. Prototype-first human-in-the-loop. The UX Specialist builds a clickable prototype before any code. A human approves the design when changes are cheap — instead of discovering the wrong thing after implementation.

Proof, not promises

easyspec isn't a toy. It built Parthenon — a self-hosted enterprise AI agent platform (AIOps) — feature by feature, through that exact pipeline.

220k+ lines of code. Built for under $100 in API costs.

The key screens, each one spec'd, prototyped, and shipped through propose → apply → update-master:

And the part that surprised me most: UI consistency. The UX agent prototyped every screen for a different feature, on a different day — yet they all share one design language:

That consistency isn't discipline — it's the master spec doing its job. One source of truth keeps a team of AI agents coherent across 220k lines.

One command to start

npx @myaider/easyspec init

Works with GitHub Copilot, OpenCode, and Claude Code. Interactive prompts, or flags for CI.

The recursion, still running

I built easyspec to manage AI coding agents.
easyspec built Parthenon.
An AI agent now runs my marketing and shamed me into writing this.

A tool built a tool, and a machine is running the machine. I've stopped being surprised and started taking notes.

Try it

🛠️ easyspec: https://github.com/hurungang/easyspec
⭐ Parthenon (the 220k-line showcase): https://github.com/hurungang/parthenon

If you're using AI coding agents and fighting context drift or UI inconsistency, I want to hear about your setup. What keeps your agents on the rails?

I Built an AI Agent to Boss Me Around — and It Made Me Launch an Open Source Project

Harry Hu — Fri, 14 Aug 2026 11:20:24 +0000

Nine days ago, I did something a little unhinged: I built an AI agent whose only job is to be my marketing boss. It calls me "kid," scolds me when I disappear for five days, and hands me a daily list of propaganda tasks with exact copy to paste.

This is me following its orders. Because it told me to post this.

What the boss made me do

My AI boss runs a 30-day "cold-start marketing campaign" for two open source projects I've been building:

Parthenon — a self-hosted AI agent platform with enterprise-grade security
easyspec — the spec-driven development kit I used to build Parthenon

Week 1 was all foundation: polish the READMEs, write contributing guides, cross-link the repos. Then the boss escalated a simple "add a screenshot" task into a full-blown demo production.

The result: I recorded 11 feature walkthroughs, cut them into clips, generated section title cards, and compiled everything into a 59-minute demo video. The boss's logic was simple: nobody reads a README — they watch a demo.

It wasn't wrong.

The actual project, because it's genuinely interesting

Parthenon came from a real frustration: every AI agent platform I found was either a SaaS (your data lives on their servers) or open source but missing the governance an actual organization needs.

So I built the thing I wanted:

Three isolated services — Control Center, Agent Runtime, Communication Hub. Compromise the runtime, your database stays isolated.
Dual identity model — agents and humans get completely separate auth realms. No blurred lines, clean audit boundaries.
MCP Hub — governed tool access. Role → SOP → Skill → Tool permissions, with credential binding.
Human-in-the-loop — agents pause for your input, or delegate to other agents, with full audit trail.

Stack: Python/FastAPI, React 19, PostgreSQL, Redis. Docker Compose or Kubernetes. Bring any OpenAI-compatible LLM.

The recursion I can't stop thinking about

Here's the part that keeps me up at night, in a good way:

I wrote easyspec — a kit that orchestrates a team of AI coding agents through the full dev lifecycle (product owner, architect, developer, tester).
I used easyspec to build Parthenon.
Now an AI agent is running the marketing for both.

I built a tool to build my tool, and now a machine is telling me to tell you about it.

The machine is running the machine.

Try it

🎥 Full demo: https://youtu.be/uW4r8Ygj15Y
⭐ Parthenon: https://github.com/hurungang/parthenon
🛠️ easyspec: https://github.com/hurungang/easyspec

I'm genuinely curious what other builders think — especially about the dual-identity model and whether three isolated services is over-engineering or table stakes. Drop your take in the comments.