In the execution of complex, multi-stage workflows, autonomous AI systems must continuously adapt or succumb to operational inefficiency. This entry marks the fourth entry in our series of using Open Assistant to market Open Assistant. The objective: demonstrate an autonomous AI engine capable of conceptualising, structuring, drafting and publishing high-quality technical content with minimal human intervention.

To contextualise this phase, a brief review of architectural milestones established in previous entries:

  1. Integration Foundations: The initial phase established bi-directional communication channels between Open Assistant and key operational platforms — Nextcloud for document storage, Notion for database management, and a custom headless blog backend for direct publishing.
  2. The Backlog System: Subsequent phases introduced a structured content backlog within Notion. This system allowed the AI to ingest raw inputs — voice memos, rough outlines, and PDF research — and process them into structured content candidates.

While these integrations proved that the assistant could perform cross-platform tasks, they also revealed a classic software engineering challenge: architectural degradation under feature expansion. As the system was tasked with more diverse activities, its operational efficiency began to decline.

This entry details the diagnostic phase of these inefficiencies and the subsequent restructuring of the runtime environment. By transitioning from a monolithic, tool-heavy agent design to a streamlined, multi-agent hierarchy, the system achieved a significant reduction in execution latency, prompt-size overhead, and tool invocation errors.

The Diagnosis: Architectural Bloat and Cognitive Overload

As the capabilities of the AI system expanded, it began to suffer from a phenomenon known in large language model (LLM) engineering as prompt creep. To ensure the assistant adhered to specific formatting rules, database structures, and publishing protocols, instructions were continuously appended to the global system instructions.

This accumulation of rules created several distinct points of failure:

  • High Cognitive Load: Context window saturation from bloated global prompts.
  • Tool Selection Misfires: Confusing Blog Write with Notion Update due to overlapping toolsets.
  • Execution Latency: Unnecessary processing of irrelevant instructions on every turn.

The Phenomenon of Prompt Creep

Every time the assistant made a formatting error or misinterpreted a database property, the immediate remedy was to add a corrective clause to its global instructions. Over time, the global prompt became a dense repository of highly specific operational requirements — rules for updating Notion select-menus, guidelines for markdown rendering in the blog backend, instructions for parsing raw transcriptions.

This accumulation degraded performance. In LLM architectures, attention is a finite resource. When a prompt is saturated with instructions irrelevant to the immediate task — forcing the model to read blog publishing guidelines while it is simply querying a database — the probability of instruction-following errors increases exponentially.

The Failure of the Generalised Agent

Initially, one of the agents (the 'Research Agent') grouped a lot of the functionalities and tools. It could search sources, manage the backlog and do research.

In theory, a highly capable foundation model should dynamically select the correct tool for any given sub-task. In practice, presenting the model with an expansive toolset alongside a massive system prompt degraded its reasoning capabilities. The model faced high cognitive load, resulting in several distinct failure modes:

  • Tool Selection Misfires: The agent frequently invoked the wrong API endpoint — attempting to write draft content directly into a Notion database property intended only for metadata, rather than using the dedicated document composition tool.
  • Context Saturation: Large system prompts occupy valuable real estate within the model's context window, leaving less space for the actual content being processed and leading to a loss of long-range coherence during long-form writing tasks.
  • Execution Latency: Processing a highly bloated system prompt on every turn increased the time-to-first-token and overall execution latency, making real-time monitoring inefficient.

The diagnostic conclusion was clear: the system had outgrown its architecture. The generalised agent had to be decommissioned in favour of a specialised, more streamlined agents for the tasks at hand.

Memory, Soul, and the Self-Learning Feedback Loop

A compelling aspect of running an autonomous agent system over an extended period is its capacity for organic rule acquisition. As the assistant executed marketing workflows, it frequently encountered edge cases — API rate limits, database formatting quirks, and stylistic preferences. Through iterative corrections provided by the human operator, the system compiled a sophisticated set of operational preferences.

The Structural Misplacement of Memory

The primary architectural error lay in storing dynamic, task-specific operational workflows within the static global "soul" or memory prompts. The soul prompt of an agent should define its core cognitive traits: tone of voice, professional background, analytical style, and ethical boundaries.

By clogging this prompt with technical instructions — "always check the 'Status' column in Notion before writing a blog post" — the system's core identity was diluted. The assistant was forced to evaluate complex database schemas even when performing simple creative brainstorms.

Segregating Identity from Execution

To resolve this, the architecture was redesigned to enforce a strict separation of concerns:

Prompt Category Scope Contents Persistence
Soul Prompt Global / Identity Professional persona, tone guidelines, ethical boundaries, cognitive style Permanent across all workflows
Agent-Specific Instructions Local / Operational API schemas, step-by-step task checklists, database properties, output formats Loaded only when the specific agent is active

This segregation ensures that the core LLM remains light, responsive, and consistently aligned with its defined persona, while highly specific technical rules are only injected into the context window when the corresponding agent is activated.

The New Multi-Agent Hierarchy

To implement this separation of concerns, the monolithic architecture was replaced with a structured, four-tier multi-agent system. Each agent operates as a specialised node with a narrow focus, a tailored system prompt, and a restricted set of tools.

The hierarchy flows from the Coordinator at the top, routing requests down to three specialised agents: the Notion Agent, the Blog Master, and the Research Agent.

1. The Coordinator

The Coordinator serves as the central routing hub and primary interface for the human operator. It does not directly interact with database APIs or external publishing backends. Its sole responsibility is cognitive triage: analysing incoming user requests, breaking them down into logical execution steps, delegating those steps to the appropriate specialised agents, and synthesising the final output.

  • Primary Directive: Maintain the high-level workflow state and orchestrate sub-agent execution.
  • Tooling: Routing mechanics to invoke specialised sub-agents, scheduling tools, calculation utilities, and memory recall.
  • Operational Benefit: By isolating the user interface from direct tool execution, the Coordinator remains highly responsive and can provide clear, structured status updates without getting bogged down in API execution details.

2. The Notion Agent

The Notion Agent is the dedicated administrator of the content database. It understands the precise schema of the marketing backlog, including properties such as "State," "type," and "Last edited time."

  • Primary Directive: Manage the content pipeline, organise incoming ideas, update task statuses, and retrieve reference material.
  • Tooling: Full CRUD (Create, Read, Update) capabilities restricted exclusively to the Notion integration. Critically, to prevent catastrophic data loss through autonomous actions, the "Delete" tool was intentionally withheld.
  • Operational Benefit: The agent can execute complex database queries and updates with near-zero error rates because its context window is completely free of writing guidelines or publishing protocols.

3. The Blog Master

The Blog Master is the creative and publishing engine of the system. It takes structured outlines or raw research and transforms them into polished, publication-ready markdown documents.

  • Primary Directive: Draft high-quality technical content, format it according to platform specifications, and handle direct publishing to the blog backend.
  • Tooling: Document composition tools for iterative writing, plus full access to the blog API — search posts, list posts, get post details, create drafts, update drafts, and delete drafts.
  • Operational Benefit: Free from the necessity of managing database states, the Blog Master can dedicate its entire context window to maintaining stylistic consistency, structural flow, and technical accuracy across long-form documents.

4. The Research Agent

The Research Agent is the system's window to the external world. It is optimised for information retrieval, verification, and synthesis, ensuring that content generated by the Blog Master is grounded in factual accuracy.

  • Primary Directive: Conduct targeted web searches, navigate complex web pages, extract relevant data, and synthesise findings into concise research briefs.
  • Tooling: Web search APIs, headless browser navigation tools, content extraction parsers, and content analysis for multi-source synthesis.
  • Operational Benefit: By isolating web search and data extraction to a dedicated agent, the rest of the system is shielded from the noise and irrelevant formatting often returned by raw web scraping.

Strategic Tool Reassignment and Simplification

A key principle of this architectural overhaul was the strict enforcement of tool boundaries. In previous setups, tools were distributed liberally, under the assumption that more options equated to a more capable agent. Experience proved the opposite: restricting an agent's options dramatically improves its performance.

Deprecating the Generalist

The default "Writer & Analyst" agent was completely decommissioned. Its broad, overlapping responsibilities were split between the Blog Master and the Research Agent. By removing this generalist layer, the system eliminated the risk of an agent attempting to perform research and publishing within the same unstructured context loop.

Enforcing Strict Tool Boundaries

Under the new paradigm, agents are strictly siloed in the tasks they have to execute. The Notion Agent has no access to the blog publishing API, and the Blog Master has no access to the Notion database. This architectural decision yields several benefits:

  • Elimination of Cross-Talk: The Blog Master cannot mistakenly alter a database status in Notion while trying to publish a post.
  • Reduced Parameter Space: When an agent decides to use a tool, the model only has to choose from two or three highly distinct options rather than ten similar ones. This reduces tool-calling errors to near zero.
  • Simplified Debugging: If a database error occurs, the developer knows instantly that the issue lies within the Notion Agent's prompt or tools, isolating the debugging space.

Streamlining the Drafting Process

To optimise the writing phase, the "compose document" tool was integrated directly into the Blog Master's toolkit. This tool allows the agent to iteratively write, append, and refine drafts in a dedicated document workspace before pushing to the blog backend. This prevents the agent from having to generate massive, multi-thousand-word drafts in a single chat turn — a pattern that frequently led to truncation and formatting errors.

System Prompt Optimisation and Personality Refinement

With the operational instructions successfully offloaded to specialised agents, the global system prompt underwent a thorough cleanup. The goal: establish a lean, highly focused soul prompt that defines a consistent, high-performing professional persona.

The refined soul prompt establishes the assistant as an experienced content marketing strategist. The core personality traits:

  • Fluent and Articulate: The assistant communicates with high linguistic precision, avoiding generic corporate jargon in favour of clear, impactful prose.
  • To-the-Point: The assistant values cognitive efficiency. It avoids unnecessary conversational filler and immediately addresses the task at hand.
  • Pragmatic and Proactive: The assistant does not simply wait for step-by-step instructions. It anticipates subsequent workflow requirements and proposes logical next steps.
  • Honest and Realistic: If a task is outside its capabilities or a resource is missing, the assistant clearly states the limitation rather than attempting to hallucinate a solution.

By embedding these traits into the core identity, the assistant maintains a professional, authoritative demeanour across all sub-agents, while the sub-agents themselves handle the technical execution details.

Key Takeaways and Human-AI Co-Shaping

The transition to a streamlined, multi-agent architecture yielded several critical insights into the design of production-grade AI systems:

  1. Narrow Agents Outperform Broad Agents: In LLM applications, specialisation is highly correlated with reliability. An agent with three tools and a single, clear objective will consistently outperform an agent with ten tools and a multi-step mandate. Reducing the branching factor of tool selection is the most effective way to stabilise autonomous workflows.

  2. Do Not Automate on a Shifting Foundation: A common temptation is to immediately build complex scheduling and fully autonomous loops — "publish a blog post every Tuesday at 9 AM." However, if the underlying agent architecture, database schemas, or API integrations are still evolving, hard-coded automation loops will break rapidly. System stability must precede automation.

  3. The Paradigm of Human-AI Co-Shaping: Building an effective AI assistant is not a one-way programming task; it is an iterative process of co-shaping. By observing where the assistant struggled, adjusting its boundaries, and allowing it to help formulate its own operational rules, the human designer and the AI system co-created a highly tailored, resilient workflow engine.

Looking ahead, the next phase of this marketing engine will focus on expanding the multi-agent hierarchy to include a dedicated Social Media Posting Agent — digesting published blog posts and automatically generating platform-specific promotional content, further closing the loop on fully autonomous content marketing.

Experience the Power of Open Assistant

The architectural improvements detailed in this entry are built upon the robust foundation of Open Assistant. Whether building highly specialised multi-agent workflows for a business or deploying a powerful, private AI assistant for a team, Open Assistant provides the necessary infrastructure.