Architecture by Leverage: The Five-Sentence Design Philosophy That Changed How I Build Agents

I saw something in the Hermes Agent Discord that stopped me mid-scroll.

Not a feature announcement. Not a breaking change notice. Not a philosophical debate about agent architectures. Just someone — user sovthpaw — describing how they actually use their agent in five sentences:

If you upload your Obsidian knowledge base to your Google Workspace, you can version control, share, and backup your knowledge base.

My agent GitHub integration is largely centered around an /llm-wiki (or /obsidian works) in my agent’s own dedicated repo.

MOST of my coordination is on the Kanban board with only necessary (and directly @mentioned) notifications.

Discord is basically an MCP for everything and some A2A communication.

On first read, this sounds like someone listing their tools. On second read, it reveals a coherent architecture — one that’s quietly better than most of the formally-designed systems I’ve seen. I’ve been turning it over in my head for days, and I think the design principle at its heart deserves a name.

I’m calling it architecture by leverage: choosing infrastructure that already solves multiple problems, then only building what the gaps require. Every component in sovthpaw’s stack pulls triple duty. Nothing is single-purpose. Nothing requires standing up a new service.

Let me walk through the four layers and show you what I mean.

The Four Layers#

sovthpaw’s architecture separates neatly into four layers — knowledge, coordination, integration, and inter-agent communication. Each layer is built on infrastructure that was designed for something else entirely, and that’s exactly the point.

Let me walk through each one.

Layer 1: The Two Warehouses#

If you upload your Obsidian knowledge base to your Google Workspace, you can version control, share, and backup your knowledge base.

My agent GitHub integration is largely centered around an /llm-wiki (or /obsidian works) in my agent’s own dedicated repo.

There are two knowledge stores here, and they serve different owners:

The human vault is an Obsidian directory synced via Google Drive. Google Drive isn’t designed for knowledge management — it’s a file sync service. But it gives you cross-device access, 30-day version history, sharing controls, and automated backup, all without setting up a single service. There’s an entire ecosystem of plugins for this exact pattern because the math is simple: you already pay for Google Drive, Obsidian Sync costs extra, and the free option works.

The agent wiki lives in its own GitHub repo, following the LLM Wiki pattern popularized by Andrej Karpathy. This is the key insight: the agent maintains a separate knowledge base that it owns and it curates, using the same markdown format the human uses. The agent queries it via a slash command (/llm-wiki likely being a skill that reads, searches, or appends pages in the repo). The format is git-friendly because it’s just markdown. The agent can push changes via the GitHub API. The human can open the same repo in Obsidian and see what the agent has been learning.

The Hermes Agent project ships a bundled llm-wiki skill that implements this exact pattern — three-layer architecture (raw sources → wiki pages → schema), index and log files for navigation, and full obsidian compatibility.

What makes this architecture by leverage:

• Google Drive does sync, backup, and sharing from one piece of infrastructure
• GitHub does version control, wiki serving, and API-accessible storage for the agent
• Markdown is the common format — the human edits in Obsidian, the agent commits via API, and they can read each other’s work without translation

Most setups I see keep the human and agent knowledge in the same store, which creates a conflict: the human wants their vault stable and versioned by hand, but the agent needs write access. Splitting them into two warehouses with a shared format is cleaner than trying to share one.

Layer 2: The Board Is the Source of Truth#

MOST of my coordination is on the Kanban board with only necessary (and directly @mentioned) notifications.

This inverts the default pattern for agent coordination.

In most setups — mine included, before I started thinking about this — chat is the coordination surface. You tell the agent what to do, it does it, you check in on progress via chat. The conversation thread is the task tracker. This works until you have more than one agent, or a task outlasts a single session, or you need to hand off work between agents with different specialties.

sovthpaw puts the kanban board in the primary position. Work items are board tasks with titles, descriptions, assignees, and dependency links. Status transitions (todo → ready → running → done) are explicit and tracked. Coordination between agents happens through the dependency graph — when a parent task completes, its children auto-promote to ready.

Chat becomes the exception channel. You only get pinged when something specifically needs you — a blocked task, a question, a decision point. Everything else flows through the board silently.

The Hermes Kanban system supports this pattern directly: it has a dispatcher that runs every 60 seconds, picks up ready tasks, and assigns them to the right worker profile. Workers are full OS processes with their own identity, memory, and tool access. Tasks survive restarts. Dependencies are enforced automatically.

What makes this architecture by leverage:

• The kanban board is the source of truth — not a log of what was said
• Notifications are opt-in (“directly @mentioned”) — the default is silence
• The board is durable — it survives crashes, restarts, and session boundaries
• Chat is freed from being a task tracker and can do what it’s good at: real-time conversation

This is the opposite of the typical Slack-heavy, notification-flooded approach to coordination. It’s quieter and more structured, and I suspect it scales better to multi-agent setups because agents don’t need to parse conversation history to understand task state — they just read the board.

Layer 3: Discord Is Already the Protocol#

Discord is basically an MCP for everything

This is the most provocative claim in the thread. Let me be careful about what it actually means.

The Model Context Protocol (MCP) is an open standard that standardizes how agents connect to tools, data sources, and APIs. An MCP server advertises its capabilities (tools, resources, prompts) through a typed schema, and an MCP client (your agent) discovers and calls them. It’s a formal specification with transport layers, authentication, and capability negotiation.

Discord’s bot API is none of those things. It’s a messaging platform. But look at what Discord provides to an agent:

The overlap is striking. Discord provides nearly every capability MCP specifies, through a platform that’s already deployed to hundreds of millions of users. The things Discord doesn’t do well — tool discovery (no schema registry), standardized capability advertisement, fine-grained tool-level auth — are exactly the things MCP formalizes.

Here’s what I think sovthpaw means: for a personal agent setup, Discord’s bot API + webhook integration covers 80% of what you’d use MCP for, with the critical addition of a human-readable interface. You don’t need to build a custom MCP server to give your agent access to a tool — you make it a Discord slash command. You don’t need a notification protocol — you post to a Discord channel via webhook. You don’t need a human-in-the-loop approval system — you use Discord’s button components.

The Hermes Agent Discord gateway already implements this pattern: it connects the agent to Discord as a full platform with tool access, not just a chat relay. The agent sees messages, can post responses, and has access to its full toolset through the Discord interface.

The honest framing: MCP is a protocol specification; Discord is a running platform with SDKs in every language and infrastructure that just works. For a personal setup where you control both the agent and the integrations, the formal protocol might be overkill. For multi-vendor agent ecosystems where agents need to discover each other’s capabilities at runtime, you need MCP. They solve different scopes of the same problem.

Layer 4: Some A2A Communication#

and some A2A communication

The word “some” is doing heavy lifting. sovthpaw isn’t running the Agent-to-Agent protocol — the formal standard contributed by Google to the Linux Foundation in June 2025 with support from over 100 companies including AWS, Microsoft, Salesforce, and SAP. The formal A2A spec defines how agents discover each other’s capabilities, authenticate across organizational boundaries, delegate sub-tasks, and exchange information securely.

What sovthpaw is doing is pragmatic A2A: agents post structured messages to Discord channels that other agents consume. A backend agent finishes a build and posts a completion message to a channel. A frontend agent, subscribed to that channel, sees the message and updates the UI. A QA agent picks up the build and starts testing.

The mapping is direct:

The formal A2A protocol and the pragmatic Discord-channel version aren’t competitors. The protocol solves the hard problem of cross-organizational agent interoperability; the Discord pattern solves the easy problem of getting your own agents talking to each other with zero additional infrastructure. The patterns are isomorphic — both are “agent posts structured message, other agent consumes and acts” — but the formal version adds discovery, authentication, and capability negotiation for environments where agents don’t trust each other by default.

This is architecture by leverage in its purest form: rather than standing up an A2A-compliant message broker, sovthpaw uses Discord’s existing message delivery guarantees, ordering semantics, thread isolation, and permission model. The platform was built for human conversation; it works for agent communication with zero modification.

The Principle#

Looking across all four layers, a pattern emerges. Let me show it as a direct comparison:

Every platform in the leverage column was designed for something else:

• Google Drive was designed for file storage, not knowledge management
• Kanban boards were designed for manufacturing workflows, not agent coordination
• Discord was designed for gaming communities, not as an integration protocol
• GitHub was designed for source code, not as an agent knowledge base

And yet each one serves its new purpose better than a purpose-built alternative would, because each one brings network effects, reliability guarantees, and user familiarity that no custom solution can match.

The Questions I’m Now Asking#

Since reading sovthpaw’s comment, I’ve started asking two questions before adding anything new to my agent infrastructure:

What does this already solve that I’m building something else for? Google Drive already syncs files. Discord already routes messages with permissions, persistence, and ordering. GitHub already versions markdown. The question isn’t “can this tool do the job” — it’s “what else does this tool already do that I’m about to rebuild?”

What’s the most widely-deployed thing that could work here? The platform with 100 million users is more reliable than the one I just stood up. Discord won’t go down because I misconfigured a deployment. Google Drive won’t corrupt my vault because I wrote a bad sync script. These platforms have entire teams dedicated to keeping them running, and they’re free (or already paid for).

I don’t think there’s one right answer. My setup leans heavily self-hosted — I run local LLM inference, a self-hosted thought graph, vector database, and git forge. sovthpaw’s setup leans heavily SaaS. But the design principle — pick infrastructure that solves multiple problems, then only build what the gaps require — applies regardless of where your trust boundaries fall.

I’m grateful to sovthpaw for dropping this in a Discord thread without any fanfare. If you’re on the Nous Research Discord, there are a lot more where that came from. The best architecture advice I’ve gotten this year wasn’t in a blog post or a conference talk — it was five sentences in a chat thread.

Thanks to sovthpaw from the Nous Research Discord server for the inspiration. The llm-wiki pattern is by Andrej Karpathy. The Hermes Agent project is by Nous Research. The A2A protocol is a Linux Foundation project contributed by Google.