tekBlueprint

Chances are many of you already use various tools to automate your work – some still at L1, others maybe reached L5 by now but haven’t told anyone about it. This article covers the L3 → L4 transition, where full automation is not very practical and frankly doesn’t make much sense. Otherwise this whole thing would devolve into yet another blog churned out by neural slop – endless streams of articles nobody asked for.

Introduction

This site already has an older article about using AI, but it covered simpler scenarios. Now I want to share my experience organizing a workflow with agent orchestration – how it works, what patterns exist, and why it works exactly this way.

Why Orchestration?

A single agent, even the most powerful one, has its own limitations:

• Context window limits: for complex tasks, even 256K tokens may not be enough, and as the LLM’s focus starts to blur, hallucination rates increase.
• Responsibility gets blurred (and with it, focus), making it hard to track errors, write clear instructions, and so on when one agent is supposed to do everything.
• A general-purpose agent or model solves narrow specialized tasks worse than a dedicated one.

When it comes to maintaining and developing a website, there are plenty of manual actions that can be forgotten, overlooked, or simply not feel like doing. The motivation for automation comes from a large number of routine tasks that have crystallized into certain recurring patterns over time. Initially this was organized as simple skills (skills), but it still required manual work. Offloading some of these tasks to LLMs with orchestration between specialized agents solves part of the problem. Instead of a set of skills and one general-purpose agent, we now build a team of specialized agents – each responsible for its own area.

Core Orchestration Patterns

I evaluated several options and picked from among them.

“Supervisor” Pattern

One central agent (orchestrator) makes all decisions and distributes tasks among executors. This is the most common approach and the one I use in my case.

“Pipeline” Pattern

Tasks flow sequentially through a chain of agents. The output of one agent becomes input for the next.

“Parallel Processing” Pattern

Multiple agents work in parallel on different parts of a task, after which results are aggregated.

“Iterative Optimization” Pattern

One agent creates a draft, a second reviews it, the first fixes it – the cycle repeats until quality is met. This variant is also partially used in my workflow.

How It Works in Practice

A hybrid of Supervisor + Iterative Optimization is the main process – work flows through a primary orchestrator that calls sub-agents. A human stays in the loop, performing a final review of results and sending items back for another iteration if needed. There’s also an automated loop between the intent-realization agent and the result-review agent – fully automated without human involvement.

This setup delivers:

• Predictability and transparency. I know which agent does what and what to expect from it.
• Quality control at every stage; critical changes pass multiple review levels. Plus, there’s confirmation before any changes are applied, and everything can be stopped at any moment.
• New agents can be added without disrupting the existing process.
• Full traceability of every change – who did what, when, and why.

Two Domains: CODE and CONTENT

In reality, there are two orchestrators because the nature of the work differs. One set of tasks is purely about website development; the other is about content.

Why is this separation critical? Because an agent writing an article shouldn’t accidentally modify hugo.toml. And an agent working with scripts shouldn’t touch article frontmatter files. Context size under the rule instructions is also reduced. Additionally, there are separate skills for more specialized work that agents know about.

If you’re interested in how local AI model deployment is organized for such tasks, I have a separate article about running local models in HomeLab. It covers the hardware and configuration details that allow running multiple models simultaneously.

CODE Orchestrator

Handles everything related to website code. Initially I wrote all scaffolding manually to create a certain site structure and examples. Thereafter, the LLM could rely on those templates and follow by example.

What gets delegated:

• Hugo templates and components.
• CSS and styling. Similar to the point above.
• JavaScript and client-side logic.
• Infrastructure (bash scripts, CI/CD).
• Configurations.

CONTENT Orchestrator

Handles content maintenance. Some tasks were initially done manually, but the process has been gradually automated.

What gets delegated:

• Article review, spelling, punctuation, style and guideline compliance, and so on.
• Creating technical recipes from rough drafts and configurations – turning chaotic materials into structured output.
• Automatic translation (RU ↔ EN). Not always great, but it’s what we’ve got.
• Generating diagrams for fast visualizing of ideas with subsequent refinement to match the project’s adopted style.
• SEO optimization – a trial agent.

Agent Team

An important consideration: a human writes the articles for the site. Well, almost :) Some articles have skeletons generated by AI and then completed or rewritten (they carry a badge label). But as stated earlier, in general agents perform auxiliary functions – review, translation, critique, drafting diagram sketches.

Orchestrators

These are top-level agents that don’t directly implement changes. They only plan, delegate, and oversee.

These orchestrators use larger parameter models with extended context so they don’t fall into context compression that loses part of the information.

Agents (Code)

Agents for working with code:

Agents (Content)

Agents for working with content:

The same principle applies here: orchestrators and reviewers use a powerful model for quality, while coding agents use a faster model for speed.

Standard Process

Now the most important part – how it all works in practice. The process consists of five phases, each with clear rules.

Phase 1: Plan

Everything starts with planning. The orchestrator analyzes the request and determines what needs to be done. For complex tasks, a .spec/FEATURE.md document is created – a detailed requirements specification. For minor fixes, a brief plan is enough. The golden rule: the plan is always shown to the user before implementation begins. No surprises.

Example plan:

Plan: fix typos in article "Homelab AI"

1. Analyze existing content in the article
2. Create .spec/AI-HOMELAB-FIX.md specification
3. Run content-reviewer for validation
4. Show diff for approval
5. Apply changes

Phase 2: Implementation

After plan approval, a specialized agent is launched via the Task tool.

For code-related tasks, a report may look like this:

Changes in templates:
- Updated layouts/partials/header.html
- Added new CSS variable for accent color
- Fixed mobile menu issue on Safari

Testing:
- Hugo local build completes without errors
- Verified on Chrome, Firefox, Safari

Important: the agent must always return not just the result but also a list of changes and decisions made. This helps during review to understand why something was done a certain way.

Phase 3: Review

A critical stage after implementation. The output goes to a reviewer who sees the changes and performs a two-stage review:

• Spec compliance – does the result match the specification?
• Quality – quality of code/content, style, formatting.

The reviewer returns their verdict: APPROVED, NEEDS CHANGES, or BLOCKED.

If NEEDS CHANGES – the cycle repeats. The agent makes revisions and goes through review again.

Example feedback from content-reviewer:

Verdict: NEEDS CHANGES

Spec compliance: PASS
- All sections from spec are present
- Internal links in correct format
- Frontmatter matches template

Quality: NEEDS IMPROVEMENT
- Paragraphs too long in "Why orchestration is needed" section
- No examples for some claims
- Agent descriptions can be supplemented with a table

Recommendations:
1. Split long paragraphs into 3-5 sentences
2. Add concrete examples from experience
3. Include a table with temperature settings for different agents

Iteration: 1/3 (max 3 iterations before escalation to human)

Example feedback from code-reviewer:

Verdict: APPROVED

Spec compliance: PASS
- Changes match .spec/FEATURE.md
- No modifications in unintended files

Quality: PASS
- Code follows project style guide
- No security issues
- Comments added for complex sections
- Tests pass successfully

Future recommendations:
- unit tests could be added for new functions

The iteration loop must be bounded (3 attempts in the example). If after the third iteration the review still says NEEDS CHANGES – the task is escalated to a human for manual resolution. This prevents infinite loops and delays.

Phase 4: Human Approval

This is where a human makes a decision. The orchestrator shows:

• A full diff of all changes (optional).
• The reviewer’s verdict.
• A brief description of what was done.

And waits for an explicit answer: yes, no, or revise (defer).

No automatic commits without approval. That’s non-negotiable.

Report format can vary – there’s no official standard yet, it takes shape dynamically. The one mandatory element is the change confirmation block.

The three response options mean different things:

• yes – changes are approved, proceed to Phase 5 (Commit)
• no – changes are rejected, the agent gets feedback and starts over
• revise – changes are saved to staging but not committed. You can return later.

Phase 5: Commit

After a yes approval:

1. Commit with a conventional commit message:
   Text

   fix(content): fixed article about AI agent orchestration

2. Delete .spec/ if a spec file was created
3. Report the commit hash

A short example of a full log:

+ Thought: 837ms

I'll review this article. First, let me read the file to understand its content.

→Read content/blog/ai/ai-orchestration-workflow/index.ru.md 

+ Thought: 910ms

Now I'll read the article and launch content-reviewer for a professional review.

✓Content-Reviewer Task -- Review article quality
↳ 2 toolcalls · 2m 46s
ctrl+x down view subagents

+ Thought: 1.5s

Review complete. Here are the results:
Review Summary
Verdict: NEEDS CHANGES
The article has good structure and useful content, but contains critical spelling errors and frontmatter issues.

---

Critical Errors (must fix):

№	Issue
1	"Ведение" → "Введение"
2	"выкристализовались" → "выкристаллизовались"
3	"повторяющие" → "повторяющиеся"
4	"скилло" → "скиллов"
5	"которой" → "который"
6	Missing period at end of sentence
7	"по началу" → "поначалу"
8	"как сказал" → "как сказано"
9	"больным" → "большим"
10	Duplicate heading "Агенты (код)" → should be "Агенты (контент)"
11	"кодинг агенты" → "кодинговые агенты"
12	Link /blog/ai/homelab-ai/ (missing leading slash)

Frontmatter Issues:
1. featuredTitle and featuredSubtitle in English for a Russian article
2. Missing description (SEO meta description)
3. Missing author
4. Title too short (40 chars, 50-60 recommended)

Recommendations:
- Remove slang ("нейрослоп", "сабагентов", "фуллстек")
- Unify terms ("оркестратор" vs "координатор")
- Expand the conclusion
- Fill empty cells in tables

Want me to run content-reviewer with instructions to fix these issues?

... TRUNCATED ...

What was left unchanged:
- ✅ Frontmatter (untouched)
- ✅ Slang ("нейрослоп", "сабагентов", "фуллстек")
- ✅ Empty cells in tables

Ready for approval

Changes are ready. Want to apply? (yes / no / revise)

Conclusion

This is the processing pipeline I’ve put together. The goal was not to overcomplicate things – sure, you could build sprawling graphs through n8n or Hermes, but I wanted to stay with familiar tools. If needed, agents and skills can be moved between various harnesses.

Multi-level review reduces the number of errors, though not all of them. Sometimes a few passes are needed, but it’s still better than checking everything alone. The most important thing is having a clear sequence of steps and rules – things that LLMs forget less often. And human involvement in decision-making is preserved, which matters.