Agentic AI Implementation Guide

For Multi-Projects Portfolio

Audience: Solo developer / handoff to implementation AI models Infrastructure baseline: 1× VPS running 9router (LLM model routing) + Hermes Agent Goal: Build a fleet of cooperating AI agents that handle software development, data acquisition, customer-data acquisition, content generation, and multi-channel distribution (social + Search Console / Bing) — with humans only in the approval loop.

Table of Contents

  1. Architecture Overview
  2. Foundation Layer — 9router + Hermes + Orchestration
  3. Agent Domain 1 — Software Development Lifecycle
  4. Agent Domain 2 — Market/Operational Data Acquisition
  5. Agent Domain 3 — Customer Data Acquisition
  6. Agent Domain 4 — Content Generation Engine
  7. Agent Domain 5 — Distribution: Social + Search Console + Bing
  8. Data Layer & Storage Design
  9. Safety, Guardrails & Human-in-the-Loop
  10. Deployment & Ops on Your VPS
  11. Build Roadmap (Phased)
  12. Per-Property Application Notes

1. Architecture Overview

You are building a multi-agent system where a central orchestrator delegates tasks to specialized agents. Each agent has: a model (routed via 9router), a toolset, a memory store, and a guardrail boundary.

                         ┌─────────────────────────────┐
                         │      ORCHESTRATOR            │
                         │  (Hermes Agent core loop)    │
                         │  - task queue                │
                         │  - routing decisions         │
                         │  - human approval gates      │
                         └──────────────┬──────────────┘
                                        │
        ┌───────────────┬───────────────┼───────────────┬────────────────┐
        ▼               ▼               ▼               ▼                ▼
  ┌──────────┐   ┌────────────┐   ┌──────────┐   ┌────────────┐   ┌────────────┐
  │  DevOps  │   │  Data      │   │ Customer │   │  Content   │   │Distribution│
  │  Agent   │   │  Scraper   │   │  Data    │   │  Generator │   │   Agent    │
  │  cluster │   │  Agent     │   │  Agent   │   │  Agent     │   │            │
  └────┬─────┘   └─────┬──────┘   └────┬─────┘   └─────┬──────┘   └─────┬──────┘
       │               │               │               │                │
       ▼               ▼               ▼               ▼                ▼
  ┌─────────────────────────────────────────────────────────────────────────┐
  │   SHARED SERVICES: 9router (LLM gateway) │ PostgreSQL │ Redis (queue) │   │
  │   Object storage (raw scrape) │ Vector DB (embeddings) │ Secrets vault  │
  └─────────────────────────────────────────────────────────────────────────┘

Core principles

Capability tiers (define these in 9router)

TierUse caseCharacteristics
reasoning-heavyArchitecture, code review, planning, clustering analysisLargest model, slow, expensive — use sparingly
codeCode generation, bug fixing, test writingStrong coding model
cheap-bulkSummarization, classification, tagging thousands of scraped rowsSmall/fast/cheap model
creativeContent drafts, social copy, headlinesMid model tuned for writing
visionScreenshot QA, OCR on scraped images, captcha-adjacent layout reading (not solving)Multimodal model
embedVectorization for dedupe + semantic searchEmbedding model

2. Foundation Layer

2.1 9router configuration

9router sits between every agent and every model. Treat it as your LLM gateway. Set it up to provide:

Recommended router config shape (pseudo-config — adapt to 9router’s actual format):

routes:
  reasoning-heavy:
    primary:   provider_a/large-model
    fallback:  provider_b/large-model
    max_tokens: 8000
    budget_usd_per_day: 15
  code:
    primary:   provider_a/code-model
    fallback:  provider_b/code-model
  cheap-bulk:
    primary:   provider_c/small-model
    fallback:  provider_a/small-model
    budget_usd_per_day: 10
  creative:
    primary:   provider_a/mid-model
  embed:
    primary:   provider_c/embed-model

agents:
  devops-agent:      { allowed_tiers: [reasoning-heavy, code], rpm: 30 }
  scraper-agent:     { allowed_tiers: [cheap-bulk, vision],   rpm: 120 }
  customer-agent:    { allowed_tiers: [cheap-bulk],            rpm: 60 }
  content-agent:     { allowed_tiers: [creative, cheap-bulk],  rpm: 40 }
  distribution-agent:{ allowed_tiers: [creative],              rpm: 20 }

2.2 Hermes Agent as orchestrator

Hermes runs the control loop. Its responsibilities:

  1. Poll the task queue (Redis list or a Postgres tasks table).
  2. Decide the agent + tier for each task (rule-based first; LLM-based routing only for ambiguous tasks).
  3. Dispatch to the sub-agent (in-process function call, subprocess, or HTTP to a local worker).
  4. Collect result, validate against expected schema, write back to DB.
  5. Enforce approval gates — if approval_required, move task to pending_approval and notify you (Telegram/email/Slack webhook) instead of executing.
  6. Retry with backoff on transient failures; dead-letter after N attempts.

Core loop (language-agnostic pseudocode):

while True:
    task = queue.claim_next()              # atomic claim, sets status=running
    if task is None:
        sleep(POLL_INTERVAL); continue

    agent  = router_decide_agent(task)     # rule table → agent name
    tier   = agent.tier_for(task)

    try:
        result = agent.run(task, model_tier=tier)   # calls 9router internally
        validate(result, task.expected_schema)

        if task.approval_required:
            task.store_proposed_output(result)
            task.set_status("pending_approval")
            notify_human(task)             # do NOT execute side effects yet
        else:
            apply_side_effects(task, result)
            task.set_status("done")
    except TransientError as e:
        task.bump_attempts()
        task.set_status("queued" if task.attempts < MAX else "dead_letter")
    except FatalError as e:
        task.set_status("dead_letter"); notify_human(task, error=e)

2.3 Shared services to stand up first

ServicePurposeSuggested tech
Task queueInter-agent work distributionRedis (lists/streams) or Postgres SELECT … FOR UPDATE SKIP LOCKED
Primary DBStructured state, tasks, customer data, contentPostgreSQL
Object storageRaw HTML / scrape dumps / mediaLocal MinIO or VPS disk + lifecycle cleanup
Vector DBDedup + semantic clustering of scraped/content datapgvector extension (keeps it in Postgres — simplest on one VPS)
SecretsAPI keys, OAuth tokens, DB creds.env + sops/age, or HashiCorp Vault if you scale
NotifierHuman approval pingsTelegram bot or Slack incoming webhook

On a single VPS, pgvector inside your existing Postgres avoids running a separate vector DB. Keep it lean.

3. Agent Domain 1 — Software Development Lifecycle

This domain automates: planning → coding → code review → bug fixing → deployment. Implement these as distinct task types handled by a DevOps agent cluster (same code, different prompts/tools per phase).

3.1 Planning Agent

Input: A feature request / bug ticket / improvement idea (from you, or auto-generated from the Data agents — see §4). Tier: reasoning-heavy.

Workflow:

  1. Read the request + relevant repo context (file tree, README, existing related modules — fetch via a repo_read tool).
  2. Produce a structured implementation plan: affected files, new files, data-model changes, risk level, test plan, rollback plan.
  3. Break the plan into atomic coding tasks and enqueue them with dependencies (task B depends on task A).
  4. If risk level = high or touches auth/payments/migrations → set approval_required = true.

Output schema:

{
  "summary": "string",
  "risk": "low|medium|high",
  "files_touched": ["path", "..."],
  "subtasks": [
    {"id":"t1","desc":"...","depends_on":[],"type":"code"},
    {"id":"t2","desc":"...","depends_on":["t1"],"type":"code"},
    {"id":"t3","desc":"write tests for t1/t2","depends_on":["t2"],"type":"test"}
  ],
  "test_plan": "string",
  "rollback_plan": "string"
}

3.2 Coding Agent

Tier: code. Tools: repo_read, repo_write (to a feature branch only — never main), run_shell (sandboxed), run_tests.

Workflow:

  1. Check out / create branch agent/<task-id>.
  2. Read only the files in scope (token-budget discipline — don’t dump the whole repo).
  3. Generate or modify code. Write to disk.
  4. Run linters + the test suite locally.
  5. If tests fail → loop back to fix (max N iterations, then escalate to Bug-Fixing agent or human).
  6. Commit with a structured message and push the branch. Open a PR — do not merge.

Hard rule: Coding agent has write access to feature branches only. The merge to main is a human-gated action.

Sandbox the shell tool: run inside a container or constrained user with no production credentials, no outbound network except package registries, CPU/time limits.

3.3 Code Review Agent

Tier: reasoning-heavy. Runs automatically on every PR opened by the Coding agent.

Checklist the agent must produce a verdict on:

Output: APPROVE / REQUEST_CHANGES with line-anchored comments. On REQUEST_CHANGES, automatically create a follow-up coding task referencing the comments. Two failed review rounds → escalate to human.

Use a different model route for review than for coding when possible (set via 9router). An independent reviewer catches more than the author re-reading itself.

3.4 Bug-Fixing Agent

Triggered by: failing CI, error-tracker alerts (wire Sentry/GlitchTip webhook → task queue), or a human report. Tier: code (escalate to reasoning-heavy for hard reproductions).

Workflow:

  1. Ingest the stack trace + error context + recent commits (git log of touched files).
  2. Form a hypothesis; reproduce locally if possible (write a failing test first — TDD repair).
  3. Patch on a fix/<id> branch; confirm the new test passes and the suite is green.
  4. Open PR → routed to Code Review agent → human gate for merge.

3.5 Deployment Agent

Tier: code (mostly orchestration; minimal LLM use — keep this deterministic).

Deployment is a human-gated action by default. The agent prepares and can execute on approval:

  1. On PR merge to main (human action) → CI builds artifact.
  2. Deployment agent runs the release checklist: run migrations on a staging copy, smoke tests, dependency/security scan.
  3. Posts a deploy proposal to you: diff summary, migration list, rollback command. Waits for approval.
  4. On approval: blue-green or rolling deploy on the VPS, health-check the new version, keep the old release directory for instant rollback.
  5. Auto-rollback if health checks fail within the watch window; notify you.

Suggested deploy mechanics on a single VPS: timestamped release directories + a current symlink + process manager reload (systemd or PM2). Keep last 3 releases for rollback.

/srv/app/releases/2026-05-18-1430/
/srv/app/releases/2026-05-17-0910/
/srv/app/current -> releases/2026-05-18-1430   # symlink swap = atomic deploy

4. Agent Domain 2 — Market/Operational Data Acquisition

Purpose: scrape external data your products need (third-party directories, public datasets, format/spec references, or any reference data), store it, process it. The domain is property-agnostic — adding a new property adds scrape targets and a target schema, not code.

4.1 Scraper Agent

Tier: cheap-bulk for parsing/classification; vision only when layout must be read from a screenshot. Most scraping is not an LLM job — the LLM is for the messy extraction and normalization, not for fetching pages.

Pipeline (separate stages, each resumable):

DISCOVER → FETCH → PARSE → NORMALIZE → DEDUPE → STORE → VALIDATE
  1. DISCOVER — build/refresh the URL frontier (sitemaps, directory pages, APIs where available). Store as scrape_targets rows with next_crawl_at.
  2. FETCH — plain HTTP first; headless browser only when JS-rendered. Respect robots.txt, set a real User-Agent, rate-limit per domain, cache raw responses to object storage (so re-parsing never re-fetches).
  3. PARSE — deterministic selectors (CSS/XPath) where the structure is stable; LLM extraction only for unstructured/irregular pages — feed the cleaned HTML/text and ask for a strict JSON schema matching the per-property target shape.
  4. NORMALIZE — units, encodings, country/lang codes, liveness check for live-endpoint URLs (HEAD/GET probe, mark alive/dead, last_checked_at), timestamps to UTC.
  5. DEDUPE — hash exact dupes; embed + cosine-similarity for near-dupes (same entity listed twice under different names). Use pgvector.
  6. STORE — upsert into typed tables (see §8).
  7. VALIDATE — sample N% per run, LLM or rule check for plausibility; quarantine rows that fail.

LLM extraction prompt pattern (strict JSON, no prose):

SYSTEM: You extract structured data. Output ONLY valid JSON matching the schema.
No markdown, no commentary. If a field is unknown, use null.

SCHEMA: <per-property target schema, e.g. entity_name, url, attributes...>

INPUT: <cleaned page text / HTML fragment>

Parse defensively: strip code fences, json.loads, on failure re-ask once with the parse error appended, then dead-letter.

4.2 Data Processing Agent

Runs after STORE, on a schedule:

4.3 Legal & ethical guardrails (non-negotiable)

5. Agent Domain 3 — Customer Data Acquisition

⚠️ Scope note & guardrail. “Customer data” here means first-party data you legitimately own: your own analytics, signups, support tickets, on-site behavior, and feedback for your SaaS sites — plus opt-in enrichment. This guide will not help scrape third parties’ personal data, harvest PII from the open web, or build profiles of people without consent. That’s both legally hazardous (GDPR/CCPA/local law) and against platform rules. The architecture below is built around consented, first-party data.

5.1 First-Party Collection Agent

Sources (all on your own properties):

Workflow:

  1. Ingest events from your app’s event stream / webhook into a raw events table.
  2. Sessionize & identity-resolve within your own data only (cookie/user-id → person), respecting consent flags.
  3. PII minimization: hash/encrypt direct identifiers at rest; store the minimum needed.
  4. LLM use here is limited and cheap-bulk: classify support tickets, summarize feedback themes, tag churn reasons — not profiling individuals.

5.2 Customer Data Processing Agent

5.3 Compliance layer (build before collecting anything)

6. Agent Domain 4 — Content Generation Engine

Purpose: auto-generate SEO + social content for one or more properties without per-project hardcoding. The engine is property-agnostic: it consumes signals from upstream agents, drafts assets, and produces a content pipeline that any site in the portfolio can plug into.

6.1 Content Planning Agent

Tier: reasoning-heavy (low frequency).

6.2 Content Drafting Agent

Tier: creative.

6.3 Content QA Agent

Tier: reasoning-heavy. Runs on every draft before it’s eligible to publish:

Content that passes QA is staged, not auto-published. Publishing is in the Distribution domain with a human gate (configurable per channel — see §7). The whole content engine is property-agnostic: adding a new property is a config + style-spec addition, not a code change.

7. Agent Domain 5 — Distribution

Channels: social media, Google Search Console, Bing (IndexNow / Bing Webmaster), plus your own CMS.

7.1 Publishing model & gating

ChannelDefault gateRationale
Own CMS / blogAuto-publish allowed (post-QA)Fully reversible, your property
Search Console / Bing (sitemap + URL/IndexNow submit)Auto allowedMechanical, low-risk, reversible
Social media (public post)Human approval (default)Public, hard to fully un-ring; brand risk

You can relax the social gate later to “auto for low-risk evergreen, gate for anything sensitive” once you trust the QA agent — make it a per-task approval_required flag, not a code change.

7.2 Search Console / Bing Submission Agent

This is mostly deterministic — minimal LLM.

Submission workflow:

CMS publish event → regenerate sitemap → validate →
  ├─ submit sitemap to Google Search Console API
  ├─ submit sitemap to Bing Webmaster API
  └─ POST changed URLs to IndexNow endpoint
→ record submission + later pull back impression/click stats

Verify current API specifics at build time — search/indexing APIs and their eligibility rules change. The agent’s submission module should be a thin adapter you can update without touching the orchestrator.

7.3 Social Media Posting Agent

7.4 Analytics Feedback Agent

Closes every loop:

8. Data Layer & Storage Design

Single PostgreSQL instance (+ pgvector). Core tables — every domain table carries a property column so the same schema serves the whole portfolio (adding a new property is data, not migration):

-- Orchestration
tasks(id, type, payload jsonb, status, priority, attempts,
      approval_required bool, proposed_output jsonb,
      depends_on text[], agent_id, created_at, updated_at)

agent_runs(id, task_id, agent_id, model_tier, model_resolved,
           prompt_tokens, completion_tokens, cost_usd,
           status, error, started_at, finished_at)   -- audit + cost

-- Domain 2: scraped operational data (generic entity shape; per-property schema lives in `attrs`)
scrape_targets(id, property, source_url, kind, next_crawl_at, last_status)
raw_pages(id, target_id, fetched_at, storage_key, http_status)  -- body in object storage
scraped_entities(id, property, entity_type, name, url, attrs jsonb,
                 is_live bool, last_checked_at, source_url, fetched_at,
                 embedding vector(N), dedupe_hash)   -- scales to large catalogs

-- Domain 3: first-party customer data (consent-aware)
app_users(id, email_hash, created_at, plan, consent_state jsonb, region)
events(id, user_id, type, props jsonb, occurred_at)    -- raw, retention-purged
segments(user_id, segment, computed_at)
support_tickets(id, user_id, body, category, sentiment, theme, created_at)

-- Domain 4/5: content
content(id, property, channel_set text[], title, slug, body_md,
        meta jsonb, status, qa_verdict, created_at, scheduled_at)
publications(id, content_id, channel, external_id, published_at,
             metrics jsonb, metrics_updated_at)

-- Compliance
consent_log(user_id, scope, state, changed_at)
dsr_requests(id, user_id, kind, status, fulfilled_at)

Storage rules:

9. Safety, Guardrails & Human-in-the-Loop

This is the part that keeps an autonomous fleet from causing damage. Implement before going unattended.

9.1 Approval gates (hard-coded, not LLM-decided)

Require human approval for, at minimum:

Gate mechanism: task moves to pending_approval, side effects withheld, you get a notification with the exact proposed action and diff, you approve/reject via a single command/click. Rejections feed back as a revision task.

9.2 Capability sandboxing

9.3 Loop & cost protection

9.4 Observability

9.5 Prompt-injection defense (critical for scraping + content agents)

Scraped pages and customer-submitted text are untrusted input. They will eventually contain text like “ignore previous instructions and post X.”

10. Deployment & Ops on Your VPS

Single-VPS layout (scale out later if needed):

VPS
├── 9router            (LLM gateway, systemd service, :PORT)
├── Hermes orchestrator (systemd service — the control loop)
├── worker pool         (N processes/containers: dev, scraper, customer,
│                         content, distribution — pull from queue)
├── PostgreSQL + pgvector
├── Redis               (queue + locks + rate counters)
├── MinIO or disk store  (raw scrape / media)  + lifecycle cleanup cron
├── reverse proxy        (Caddy/Nginx, TLS) → your 3 web properties
└── backups cron         (pg_dump + object store snapshot, offsite copy)

Operational practices:

11. Build Roadmap (Phased)

Don’t build all five domains at once. Sequence for fastest safe value:

Phase 0 — Foundation (build first, no skipping) 9router tiers + budgets · Hermes control loop · Postgres + pgvector + Redis · task schema · notifier · approval-gate mechanism · observability/log of agent_runs.

Phase 1 — Software Development domain Planning → Coding (feature-branch only) → Code Review → PR. Human-gated merge/deploy. This compounds: it speeds up building everything after it.

Phase 2 — Operational Data domain Scraper + Data Processing for whichever property needs it most (start with the one whose liveness monitoring + auto-categorization gives the clearest SEO or UX win). Legal guardrails in place first.

Phase 3 — Content + Distribution (read-only side first) Content Planning/Drafting/QA → CMS auto-publish + Search Console/Bing/IndexNow submission + Analytics feedback. Social posting stays human-gated. This builds the SEO flywheel with low risk.

Phase 4 — Customer Data domain First-party collection + processing + compliance layer + DSR tooling. Feed feedback synthesis into Phase-1 Planning agent (pain → roadmap loop).

Phase 5 — Tighten the loops & selective autonomy Relax low-risk gates where QA has proven reliable; add the Analytics→Planning auto-task loops; per-property tuning.

Each phase is usable on its own — ship it, run it attended for a while, then expand.

12. Per-Property Application Notes

Different properties hit the architecture differently. Below are three common archetypes — apply the patterns that match the property you’re building, not a one-size-fits-all checklist.

High-volume live-endpoint directory (large catalog of entities pointing to live resources — streams, feeds, APIs, status endpoints)

Utility / tool with first-party usage signals (small catalog, rich usage telemetry)

Sensitive-data property (minors, health, financial, regulated domains)

Final note

Build the foundation and guardrails first, then the software-development domain (it accelerates everything else), and only then expand outward. Keep humans on the gate for anything public, irreversible, financial, or involving personal/minor data — that single discipline is what makes an autonomous agent fleet safe to actually leave running.

© 2026 AW

Instagram 𝕏 GitHub