The first Automation Diary entry covered the initial deployment — wiring up integrations, registering the blog CMS as a plugin, and establishing the principle of least privilege. The system worked. Three blog posts shipped. But a working system and an optimized system are two very different things.
This second entry picks up where the first left off: refining the agent architecture, tightening the writing style, and learning the most important lesson in agentic system design — less is more.
The Writing Style Problem: Timelessness Over Timestamps
After the first blog posts went live, a pattern emerged in the output. The assistant was writing competently, but the tone carried a specific kind of immediacy — references to "yesterday," casual openers, and self-referential language (referring to itself by name in the prose). These are fine for a personal journal. They are less fine for content intended to remain relevant months from now.
The correction was direct: write timeless content. No temporal anchors. No self-referential asides. The blog posts should read as durable technical documentation, not timestamped diary entries written by an AI that happens to know its own name.
The assistant absorbed the feedback, redrafted the existing posts, and — critically — updated its own system prompts to internalize the preference. This is the loop in action: human feedback → system-level adaptation → improved default behavior. No code changes. No manual configuration file edits. Just a conversation that permanently shifted the system's writing posture.
A call-to-action section was also added at the end of each post — a small structural element that the assistant now includes by default on every new draft.
Agent Architecture: The Case for Fewer Moving Parts
The default Open Assistant deployment ships with four agents: a Research Agent, a Browser Agent, a Content Writer Agent, and a File Handler Agent. For a general-purpose setup, this is a reasonable starting point. For a focused content-production system, it's overkill.
The Problem with Too Many Agents
Each agent in the system carries its own prompt, its own tool assignments, and its own intent keywords. When a user message arrives, the system evaluates which agents to activate based on keyword matching and priority ordering. The more agents in the roster, the more surface area for misrouting — a request lands on the wrong agent, picks up the wrong context, or triggers a tool that shouldn't be involved.
Conversely, assigning too many tools to a single agent creates a different failure mode: the agent becomes a bloated generalist, uncertain which tool to reach for and prone to unnecessary intermediate steps.
The sweet spot is lean and purposeful — enough agents to maintain clear separation of concerns, few enough that the routing logic remains predictable.
The Reorganization
The original four-agent layout was consolidated into three:
BEFORE (4 agents) AFTER (3 agents)
───────────────── ─────────────────
1. Research Agent 1. Research Agent (expanded)
2. Browser Agent ──► merged ──► 2. Content Writer Agent (unchanged)
3. Content Writer Agent 3. Blog Master (unchanged)
4. File Handler Agent ──► merged ──►
Browser Agent — deleted. Its web-browsing capabilities were folded into the Research Agent, which already handled information retrieval. Running a separate agent just to fetch a web page added routing complexity without adding capability.
File Handler Agent — deleted. The content-production workflow relies on two storage backends: Nextcloud for organized content and final files, and Notion for raw ideas and scribbles. Both are already accessible to the Research Agent. A dedicated file handler for generating PDFs, Word documents, and HTML pages was premature — the system doesn't need those outputs yet. The file deletion tool was preserved by moving it into the Research Agent's toolkit.
Content Writer Agent — kept as-is. It handles the core drafting and analysis workload: composing documents from raw input and producing structured written output.
Blog Master — kept as-is, with one targeted update. During the first diary's workflow, the assistant needed to be reminded that embedded video iframes should span the full width of the post. Rather than relying on repeated instructions, this formatting rule was added directly to the Blog Master's backstory. One correction, permanently absorbed.
The Research Agent: Internal Knowledge Base Meets the Web
With the Browser and File Handler agents absorbed, the Research Agent became the system's primary information interface. Its backstory was rewritten to reflect this expanded scope:
You have access to Nextcloud, where you can find the actual content system; Notion for notes and scribbles; and the web for broader searches. You must use your tools to answer questions. Never guess or fabricate information.
The strategy embedded in its prompt is a simple decision tree:
- Internal query? → Use unified search (Notion, Nextcloud).
- External query? → Use web tools.
- Unclear? → Ask the user for clarification.
Intent keywords were curated to match the agent's actual responsibilities: search, find, list, browse, web, page. No mail-related keywords (Gmail, Outlook) — this system doesn't handle email.
Agent Priority: Why Ordering Matters
When a user message doesn't match any intent keyword, the system falls back to selecting agents by priority order. The top agents in the list become the default responders.
The current priority stack:
- Coordinator — the central orchestrator, always first.
- Research Agent — the information backbone.
- Content Writer Agent — the drafting engine.
- Blog Master — the publication specialist.
With only four agents, misrouting is unlikely regardless of order. But as the system grows — and it will — priority placement becomes a real lever for controlling default behavior. Getting the ordering right early prevents a class of routing bugs that only surface at scale.
The Small Backstory Principle
A recurring theme throughout this reorganization: start small, adapt as you go.
Each agent's backstory was kept deliberately brief at launch. The temptation when configuring an agentic system is to write exhaustive prompts — detailed role descriptions, edge-case handling instructions, personality specifications. The reality is that over-specified prompts create rigidity. The system can't adapt to patterns it hasn't been explicitly told about.
A short backstory gives the agent room to learn from interaction. When the assistant made a formatting mistake (narrow iframes), the correction was added to the backstory. When the writing style drifted toward the casual, the feedback was absorbed into the system prompts. Each adjustment was small, targeted, and permanent — without requiring a rewrite of the entire configuration.
This is the same philosophy as the agent count: start lean, observe, and expand only when a genuine need emerges.
Scheduled Jobs: Automations That Depend on Agent Configuration
The system currently runs four recurring cron jobs:
- Nightly Soul Update — refines the assistant's personality prompt based on recent conversations.
- Nightly Memory Update — extracts and stores operational facts from the day's interactions.
- Outlook Refresh — syncs external calendar/email state.
- Temporary Directory Cleanup — purges stale working files.
These jobs execute recipes — ordered sequences of tool calls — that depend on specific agents having specific tools. When agents are reorganized (tools moved, agents deleted, backstories rewritten), the recipes can break. A job that calls a tool now assigned to a different agent, or an agent that no longer exists, will fail silently or throw errors.
This is a subtle but important coupling: agent architecture changes cascade into automation reliability. Any reorganization must be followed by a review of active cron jobs to verify that their tool references still resolve correctly.
What Comes Next
The three-agent core — Research, Content Writer, Blog Master — is stable. The next expansion targets two auxiliary capabilities:
-
Social Publishing Agent — dedicated to distributing content across social channels. Currently, publishing stops at the blog. The natural next step is automated cross-posting with platform-specific formatting.
-
Graphic Design Agent — automated visual asset generation for blog posts and social content. The automation here is still early-stage; expect iterations.
Both will be added as separate agents rather than folded into existing ones. The principle remains: dedicated agents for dedicated responsibilities, but only when the responsibility justifies the routing complexity.
The workflow from voice note to published draft is now a single prompt. Send a transcript, review the draft, approve. The system handles transcription, structuring, formatting, and draft creation. The human handles judgment.
That's the architecture. That's the iteration. On to the next one.
Get Started
Ready to build your own AI-powered content pipeline? Create an Open Assistant instance and start configuring — or learn more at open-assistant.org.