AI Agents in Practice Beyond Coding

Most discussions about AI agents focus on software development. Agents that write code, run tests, deploy applications. That is impressive, but it misses the bigger picture. The more interesting question is: what happens when you apply the same agent architecture to knowledge work?

This book is the answer. Every chapter, every article, the website, the PDF, the EPUB, the email drafts sent to co-authors, the consulting logs, the contact profiles, the architecture diagrams: all of it runs through an AI agent system built on top of an Obsidian vault. Not as an experiment, but as the daily production environment.

This article describes the architecture as of March 2026. It changes constantly. By the time you read this, some components will have evolved further. That is the point.

The Architecture

The AI agent architecture: Obsidian as knowledge hub, Claude Code as AI engine, specialized skills, MCP server integrations, and output channels

The system has five layers.

Layer 1: The User. A consultant, trainer, or author sits in front of Obsidian, a Markdown editor that serves as the knowledge hub. All content lives as plain Markdown files in a Git-versioned vault. The book chapters, client notes, email drafts, contact profiles, architecture diagrams: everything is text.

Layer 2: Obsidian + Claude Code. Obsidian connects to Claude Code through an ame3helper plugin and the Obsidian CLI (available since Obsidian 1.12). Claude Code is a coding agent, but “coding” is just the mechanism. The real capability is tool orchestration: reading files, editing content, calling APIs, spawning sub-agents, and managing persistent sessions.

Layer 3: 50+ Specialized Skills. Skills are pre-written prompts combined with pseudo-code scripts. They fall into four categories:

• Agents execute tasks autonomously: send emails, research contacts, build the book, transcribe recordings.
• Assistants work collaboratively: the Book-Writing assistant loads all chapter summaries into context before helping write. The Email assistant drafts messages but never sends without approval.
• Actions operate on specific content: rewrite a selected paragraph, link a mentioned person to their contact note.
• Infra skills manage the system itself: session tracking, note connections, tool memory.

Each skill is a Markdown file containing pseudo-code instructions. Not natural language, not full programming. Pseudo-code, because it constrains the model’s behavior more reliably than prose.

Layer 4: MCP Servers. The Model Context Protocol connects Claude Code to external services. Google Workspace (Gmail, Calendar, Drive), IMAP for additional email accounts, Miro for workshop boards, Airtable for customer and training databases, and vault-rag for semantic search across the knowledge vault. Each server provides a structured API that the agent can call autonomously.

Layer 5: Output. The results: the ame3.ai website (Hugo), the book (PDF, EPUB via Quarto), email drafts in Gmail, LinkedIn posts, PDF letters with corporate branding, Miro boards for workshops.

How the Book Gets Built

The Book-Writing assistant is the most complex skill in the system. When started, it loads compressed context summaries of all book chapters into its working memory. This gives it awareness of the entire book structure, terminology, cross-references, and narrative flow before it writes a single word.

The publishing pipeline works like software deployment:

1. I write or edit a chapter in Obsidian as plain Markdown.
2. The ame3helper plugin exports content to Hugo (website) and Quarto (book).
3. Quarto renders the full book as PDF and EPUB, using LaTeX under the hood. I have never looked at the LaTeX. Vibe coding in its purest form.
4. A test agent verifies that the website builds correctly and that links resolve.
5. Everything is versioned in Git. Andreas and I work like a software team: he writes articles, I review the merge request, approve it, and the next build publishes automatically.

This workflow exists because AI agents are not reliable enough to trust blindly. Every generated output passes through version control and human review. The agent proposes. The human disposes.

Memory and Retrospectives

The most underestimated capability is learning across sessions. AI models have no memory between conversations. Every new session starts from zero.

The solution is a structured memory system: Markdown files that capture rules, preferences, and context. After every task, a Learn and Remember agent analyzes what happened and proposes improvements to the skills or new memory entries. This is essentially a retrospective. The agent identifies what could work better, I review the suggestions, and the ones that make sense get merged into the system.

Over time, this compounds. The email skill learned to never send without approval. The book assistant learned to check cross-references before editing. The consulting agent learned which log format I prefer. None of these rules were written upfront. They emerged from practice.

AI in Consulting

Where this system truly proves its value is in consulting work. I keep a structured log for every client engagement: what we discussed, what the action items are, what changed since last time. Two weeks between meetings, sometimes two months. Without notes, context is lost.

With the consulting agent, I can ask: “What was the product strategy we discussed in the last session?” and get an accurate answer pulled from the log, the email history, and the calendar. Before a sprint transition, I can say: “The next sprint transition should be one and a half days. Draft an agenda based on improvements from the last retrospective.” Two minutes later, a complete agenda exists, consistent with previous sessions.

Contact profiles update automatically. When I add a new contact, the agent searches public data, pulls relevant information from past email exchanges, and creates a structured profile. This is not magic. It is structured access to data that already exists but would take thirty minutes to assemble manually.

Virtual Teams of Specialist Agents

Andreas takes this further for training development. When building a new course module, he does not rely on a single agent. He deploys multiple specialist agents, each with a different perspective:

• A learning objectives agent checks whether the course actually covers the declared learning goals.
• An experienced trainer agent reviews whether the session timing is realistic.
• A narrative agent evaluates whether the course elements have a coherent storyline or are just assembled pieces.

Each agent produces independent feedback. The combined output resembles a review from a diverse team. This is practical today. Not a research concept, not a demo. A working tool that catches problems a single reviewer would miss.

What We Learned

Pseudo-code beats natural language for skills. Writing prompts as pseudo-code forces logical structure and produces more predictable behavior. Natural language is ambiguous. Pseudo-code is not.

Version control is non-negotiable. AI agents create and destroy content. Without Git, a single bad run could overwrite hours of work. The coding agent’s undo capabilities help, but a proper version history is the real safety net.

Human-in-the-loop is not optional. Prompt injection is a real risk. An incoming email could contain hidden instructions. An agent with full autonomy could leak data or send embarrassing messages. Every sensitive action requires explicit approval.

Start with software development practices. Test-driven development, code review, version control, continuous integration: these practices exist because humans make mistakes. AI agents make different mistakes, but the same practices apply. Treat content like code.

The tools change constantly. Six months ago, this system ran on a custom API integration. All of that was discarded and rebuilt on Claude Code, because it was simply more capable. Next month, something else might change. Build for evolution, not permanence.

The Energy Question

This needs to be said honestly. Running a model like Opus is energy-intensive. Every prompt, every search, every sub-agent costs computation and therefore electricity. The cost is roughly 150 to 200 dollars per month per person for heavy use. The energy behind that number is not trivial.

Efficiency improvements will come. Smaller models handle simpler tasks already. The system routes research queries to lighter models automatically. But the fundamental trade-off remains: powerful AI agents consume significant resources. Whether the productivity gain justifies the environmental cost is a question every user must answer for themselves.

What This Means for Enterprises

The architecture described here runs on a single consultant’s laptop. It is not enterprise infrastructure. But the patterns transfer directly.

Knowledge management becomes executable. Instead of documentation that nobody reads, knowledge lives in a structured vault that agents can query, update, and act on.

Specialist agents replace specialist roles for routine tasks. Not the deep expertise, but the routine application of that expertise: reviewing compliance, checking consistency, drafting standard communications.

Software development practices become universal. Version control, code review, continuous integration, test automation: these are no longer limited to software teams. Any team that works with text, data, or structured content can benefit.

The AI-Enhanced Team is not a team that writes code faster. It is a team that owns an entire value chain, from customer need to delivered outcome, with AI agents handling the routine while humans focus on judgment, relationships, and decisions under uncertainty.

We are not there yet. But the architecture is already working.