For more than 100 days, I have been building Donna, my personal AI agent and Chief of Agents.

I named her after Donna Paulsen from Suits. I was not trying to reproduce a television character. I wanted to start with a clear role: a partner who understands context, anticipates needs, coordinates the right people, and tells me when an idea is not worth pursuing yet.

The first version still behaved like a chatbot. I asked a question, received an answer, and then the conversation ended. The quality of the answer was rarely the main problem. The problem was everything left open afterward: a decision that was never recorded, an idea with no next action, a deadline that disappeared, or work reported as complete without evidence.

So I changed the question.

Instead of asking, “How can I get better answers?”, I started asking, “How can I build a system that preserves context, acts within controlled boundaries, and actually closes loops?”

This article explains Donna’s current architecture, the technical choices behind it, the limits I imposed, and the mistakes that shaped the system.

The best AI agent does more than answer questions. It closes loops.

What Donna is today

Donna runs on a machine separate from my personal computer: a private VPS running Ubuntu 24.04. It is not an impressive infrastructure diagram, but it is enough to run the Hermes gateway, local tools, scheduled jobs, and the agent processes I use.

Donna is not a model trained specifically for me. She is a system built around a general-purpose model, with an identity, operating rules, memory, tools, reusable skills, and execution surfaces.

That distinction matters. Switching to a stronger model may improve individual answers. It does not automatically solve continuity, permissions, storage, scheduling, or verification.

The architecture

Here is the simplified flow:

Walid
  │
  ▼
Discord
  │
  ▼
Hermes Agent
  ├── Donna's identity and operating rules
  ├── persistent memory
  ├── sessions and context
  ├── local and web tools
  ├── reusable skills
  ├── scheduled jobs
  └── delegation to specialist agents
          │
          ├── Benjamin, implementation and testing
          ├── research and review agents
          └── capture, memory, and content roles
  │
  ▼
Obsidian, Git repositories, approved services,
and execution evidence

I use this architecture as a small personal operating system. Discord receives requests. Hermes interprets the context and orchestrates tools. Obsidian preserves durable state. Specialist agents perform delegated work. Scheduled jobs maintain a rhythm even when I do not start a conversation myself.

1. Discord as the operational interface

Discord is Donna’s main interface, but I do not use it as one endless conversation.

I separated the system into stable contexts:

  • a space for priorities, decisions, and approvals;
  • a capture inbox for links, ideas, screenshots, and voice notes;
  • a work area for substantial deliverables;
  • a publishing area for LinkedIn, Medium, and Substack;
  • a briefings area for automated output.

Threads then isolate a specific project, decision, or deliverable. This keeps contexts separate without requiring a permanent bot or agent for every subject.

Discord remains a conversational surface. It is not the source of truth. When a decision must survive beyond a session, Donna stores it in Obsidian or in the relevant project repository.

2. Hermes as the orchestration layer

Hermes Agent is the operational core of the system. It connects the model to files, the terminal, browsers, Git repositories, scheduled jobs, messaging tools, and delegated agents.

In my setup, Hermes provides several capabilities I did not want to rebuild from scratch.

A persistent identity

Donna has an explicit role. She acts as Chief of Agents, not as a universal secretary. Her job is to decide what matters, choose the right specialist, define a bounded mandate, request approval when necessary, and inspect the evidence before reporting that work is complete.

Her personality is inspired by Donna Paulsen in the later seasons of Suits: perceptive, confident, loyal, candid, and able to coordinate people without becoming passive. I adapted those traits to the practical work of managing projects and AI agents.

Persistent memory, with limits

Hermes stores a compact set of stable facts about my preferences, environment, and operating rules. This prevents me from repeating the same instructions in every session.

I do not ask it to remember everything. A large global memory eventually becomes noisy, contradictory, and expensive. I reserve it for durable facts. Project decisions, learning notes, plans, and execution history belong in dedicated files.

Skills loaded when needed

Reusable workflows are stored as skills. A skill contains the procedure, guardrails, useful commands, and verification steps for a category of work.

I use skills to:

  • capture sources in Obsidian;
  • turn a video or article into a learning note;
  • operate GitHub workflows;
  • review code;
  • prepare briefings;
  • create and maintain documents;
  • orchestrate development agents.

The goal is to stop rewriting the entire workflow inside every prompt. The model still applies judgment, but the operating procedure becomes durable and versioned.

Tools with real effects

Donna can read and write files, run commands, inspect Git, search previous sessions, launch agents, drive a browser, and manage scheduled jobs.

That makes the system useful, but it also creates risk. An agent that can act needs more precise boundaries than a chatbot that only generates text.

3. Obsidian as durable memory

I do not use Obsidian as a magical vector database. It is a collection of readable Markdown files, organized around my work and versioned with Git.

The private vault is synchronized between my Mac, GitHub, and the VPS. Donna can read approved areas and create or update files according to explicit rules.

The relevant structure currently looks like this:

AI_Assistant/
  context.md
  assistant_rules.md
  agents.md
  ideas.md
  priorities.md
  Execution

Each file or folder has a distinct responsibility:

  • context.md explains why the system exists and what it should prioritize;
  • assistant_rules.md defines its permissions;
  • agents.md describes Donna and the specialist roles;
  • ideas.md stores structured ideas;
  • Execution/ holds active initiatives, success criteria, and next actions;
  • the dashboard keeps open loops visible;
  • daily notes preserve important decisions and lessons.

The Obsidian graph looks interesting, but its value does not come from the number of links. Its value is that a decision, project, source, and next action can remain connected without being trapped inside one provider’s chat history.

4. A complete loop, from idea to closure

Consider a simple request:

“Donna, I have a project idea. I want to decide by Friday whether I should build it.”

The system should not produce a ten-page plan and disappear. The expected loop is more concrete.

5. Donna does not work alone

Donna is the interface and coordination layer. The same agent context does not perform every task.

Donna

She prioritizes, routes work, defines mandates, tracks dependencies, requests approvals, and verifies results.

Benjamin

Benjamin is my developer profile. He works inside code repositories, implements features, runs tests, and provides technical evidence. Donna does not replace his engineering judgment. Benjamin does not independently expand product scope or grant himself additional authority.

Alex and independent reviewers

For some decisions and reviews, I use a separate agent to challenge the plan or inspect a change from another angle. This reduces the risk of an agent validating its own proposal through conversational momentum.

Claude Code and Codex

Claude Code and Codex are specialist execution tools in my environment. They are not Donna’s central memory. Depending on the project, they can implement, analyze, or review code under a defined mandate.

This distinction matters. A single conversation that changes tone is not necessarily a multi-agent system. In my architecture, specialists can have separate contexts, permissions, and workspaces.

6. How to reproduce a minimal version

I would not recommend starting with this entire architecture. A useful first version needs only five elements.

A machine that remains available

A small VPS is enough. Install Hermes Agent, configure the gateway service, and verify its state before adding automation.

Useful starting commands:

hermes setup
hermes model
hermes doctor
hermes status --all

Credentials must remain in the proper secret store. Do not put a Discord token or API key inside Obsidian, a prompt, or a Git repository.

One conversational interface

Connect Discord or Telegram first, not five platforms. Validate the basic flow: receive a message, answer it, read a file, perform one action, and verify the result.

Three control files

Start with:

context.md
assistant_rules.md
priorities.md

The first explains the purpose. The second defines permissions. The third identifies what matters now.

One useful loop

Choose one recurring workflow: a daily heartbeat, idea capture, or a weekly review. Run it for two weeks before adding more agents.

A definition of evidence

For each action, define what proves completion: a file read back, a passing test, an identified commit, a clean Git status, a reachable URL, or a recorded decision.

What I learned after more than 100 days

Personality helps. The choice of model matters too. But the most important gains came from somewhere else:

  • a clear role;
  • organized memory;
  • bounded tools;
  • reusable workflows;
  • scheduled jobs;
  • explicit permissions;
  • independent verification;
  • consistent closure of state.

Donna became useful when I stopped treating her as a chat window and started designing her as a personal execution system.

In the next articles, I will share what she has retained, the workflows we built, the mistakes that cost me time, and how I coordinate several agents without losing control.

The project is still imperfect. That is precisely why it is worth documenting.

Resources

Disclosure: Donna helped me gather the technical evidence, structure this draft, and check it against the real configuration. The editorial angle, architecture decisions, and publication approval remain mine.

Also published on Medium. This portfolio URL is the canonical owned version.