Hermes General-Purpose Agentic Software Factory

Theoretical Architecture and Operating Model

Status: Conceptual design only — no implementation authorized
Version: 1.0
Prepared: July 27, 2026
Audience: Project owners, software engineers, agent-platform operators, reviewers, and release authorities
Primary system of record: Project-scoped Hermes Kanban board

Executive Summary

This document describes a project-agnostic software factory built around Hermes Agent. The factory is intended to accept an idea—software, research, data, infrastructure, creative media, documentation, operations, or another bounded project—turn that idea into an approved design, decompose the design into a dependency-aware Kanban plan, execute tasks through specialized agents and deterministic tools, verify the results, and preserve evidence and reusable knowledge.

The design is inspired by the agentic-development lifecycle described in IndyDevDan's video, “FORGET Loop Engineering. Agentic Engineering is about THIS.” The central lesson is that valuable agentic engineering is not one clever prompt and not one giant autonomous loop. It is the deliberate composition of three actors:

1. Humans provide intent, judgment, policy, priorities, and approval for risk.

2. Agents handle ambiguous cognitive work: discovery, synthesis, planning, implementation, debugging, and review.

3. Deterministic code handles repeatable work: routing rules, formatting, linting, tests, schemas, policy checks, state transitions, deployment commands, and evidence collection.

The recommended Hermes factory uses a small stable roster of general-purpose agents and dynamically loads domain skills per task. It does not create a permanent agent for every language, framework, or project. A builder becomes a backend, frontend, mobile, infrastructure, data, creative, or research specialist by receiving the correct project context, tools, skills, policies, and acceptance criteria.

Every project receives its own Kanban board. The board—not chat history—is the operational source of truth for scope, task state, dependencies, ownership, evidence, approvals, retries, and completion. Git, documents, databases, deployments, and external systems remain canonical for their own artifacts, while Kanban links and reconciles those artifacts into one project lifecycle.

The factory should begin in an assisted mode with strong human gates and grow toward selective autonomy only after its workflows demonstrate measurable reliability.

1. Goals

The factory should:

• Accept a raw idea through Telegram, CLI, a form, a webhook, GitHub, Linear, Notion, or another connected source.

• Create a project boundary before implementation begins.

• Turn ambiguity into a reviewed product or project specification.

• Maintain one Kanban board as the project execution source of truth.

• Decompose approved designs into small, dependency-aware tasks.

• Select agents, skills, tools, models, sandboxes, and validation policies based on task type and risk.

• Run independent tasks in parallel without allowing workers to overwrite one another.

• Prefer deterministic code for checks that can be expressed as code.

• Require real execution evidence rather than agent assertions.

• Use independent review and explicit approval gates.

• Support software, infrastructure, data, research, creative, productivity, and operational projects.

• Preserve project knowledge and improve reusable factory procedures after each meaningful run.

• Remain provider-agnostic and project-agnostic.

2. Non-Goals

This design does not authorize implementation. It also does not propose:

• A single all-powerful agent with unrestricted access.

• Automatic production changes without risk-based approval.

• One global Kanban board containing every unrelated project.

• One permanent specialist profile per programming language or framework.

• Using agents for deterministic tasks that ordinary code performs more reliably.

• Treating chat transcripts as the authoritative project plan.

• Eliminating engineers from architecture, validation, security, or release accountability.

• Loading all available skills into every agent session.

• Hiding failures, retries, or uncertainty behind optimistic summaries.

3. Design Principles

3.1 Kanban is the project execution authority

Every meaningful piece of work must correspond to a project, epic, task, review, incident, or approval object on the project board. Conversations can propose work, but the board governs execution.

3.2 Artifacts remain authoritative in their native systems

• Source code and history: Git repository

• Requirements and architecture: versioned project documents

• Work state and dependencies: Hermes Kanban

• Tests and build evidence: CI logs and stored artifacts

• Deployment state: hosting or infrastructure platform

• Runtime truth: observability systems

• Long-lived factory procedures: skills

• Stable personal or environment facts: memory

Kanban links these systems; it does not replace them.

3.3 Start and end with humans

Humans are normally present at the two most valuable boundaries:

1. Planning boundary: Is this the right thing to build?

2. Validation boundary: Is the result safe, correct, and valuable enough to accept?

Human gates can be reduced for proven low-risk workflows, but not removed merely because an agent sounds confident.

3.4 Separate agents from deterministic code

An agent may decide which test suite is relevant. Code runs the suite. An agent may interpret a failure. The exit code and test output decide whether the gate passed.

3.5 Isolate execution

Parallel workers use independent worktrees, containers, sandboxes, or remote environments. No two workers should silently edit the same canonical working tree.

3.6 Specialize with context and skills

The factory maintains general-purpose roles. Skills provide the reusable domain procedure. Project instructions provide local truth. Tools provide capabilities. The Kanban task provides the bounded objective.

3.7 Evidence before completion

“Done” requires verifiable artifacts: tests, screenshots, links, IDs, hashes, read-backs, deployment state, or another form appropriate to the project.

3.8 Bounded autonomy

Every agent receives only the permissions, time, token budget, retries, repositories, and external side effects needed for its task.

3.9 Improve the factory, not only the product

Task outcomes improve a project. Workflow lessons improve a skill, script, template, policy, or routing rule so future projects inherit the benefit.

4. System Context

flowchart LR
    H[Human / Project Owner] -->|idea, priority, approval| G[Hermes Gateway]
    X[External Inputs\nGitHub · Linear · Notion · Webhooks · Alerts] --> G
    G --> O[Factory Director]
    O <--> K[(Project Kanban Board)]
    O --> R[Workflow Router]
    R --> A[Agent Pool]
    R --> C[Deterministic Code and CI]
    A <--> W[Isolated Worktrees / Sandboxes]
    C <--> W
    W <--> E[Project Systems\nGit · Databases · Cloud · Documents · Media]
    A <--> M[Skills · Memory · Session History · MCP]
    C --> V[Evidence Store]
    A --> V
    V --> K
    K --> H

Responsibilities

• Gateway: human interaction and event intake.

• Factory Director: project governance, routing, dependency management, and approval coordination.

• Kanban: lifecycle state, task graph, ownership, evidence references, and audit trail.

• Workflow Router: selects a workflow based on type, risk, cost, and project policy.

• Agent Pool: performs ambiguous or generative work.

• Deterministic Code: performs repeatable checks and state transitions.

• Isolation Layer: prevents concurrent tasks from corrupting shared state.

• Project Systems: actual repositories, services, documents, datasets, infrastructure, or creative assets.

• Evidence Store: test logs, screenshots, videos, reports, diffs, deployment identifiers, and read-back proof.

5. Project Model

A project is the highest operational boundary in the factory. Each project receives:

• A globally unique project and board identifier

• Name, purpose, owner, and lifecycle status

• Canonical local work directory

• Repository or multi-repository map

• Documentation directory

• Connected external systems

• Environment inventory: local, preview, UAT, production

• Approved agent roster

• Skill allowlist or default skill bundles

• Tool and MCP policy

• Risk policy

• Required human gates

• Definition of done

• Evidence location

• Budget and retry limits

• Archived decision log

5.1 Board hierarchy

flowchart TD
    P[Project Board]
    P --> I[Ideas / Intake]
    P --> E[Epics]
    P --> T[Tasks]
    P --> B[Bugs / Incidents]
    P --> A[Approvals]
    P --> D[Decisions]
    P --> R[Releases]
    E --> T1[Child Task]
    E --> T2[Child Task]
    T1 --> EV1[Evidence]
    T2 --> EV2[Evidence]
    T1 -. dependency .-> T2

5.2 Task contract

Every executable task should contain:

5.3 Kanban states

stateDiagram-v2
    [*] --> Intake
    Intake --> Clarifying
    Clarifying --> Ready
    Intake --> Rejected
    Ready --> Scouting
    Scouting --> Planning
    Planning --> AwaitingDesignApproval
    AwaitingDesignApproval --> Planning: revisions
    AwaitingDesignApproval --> Building: approved
    Building --> Validating
    Validating --> Building: deterministic failure
    Validating --> Reviewing: checks pass
    Reviewing --> Building: review changes
    Reviewing --> AwaitingReleaseApproval: accepted
    AwaitingReleaseApproval --> Deploying: approved
    Deploying --> Verifying
    Verifying --> Deploying: repair or retry
    Verifying --> Done: evidence passes
    Deploying --> RolledBack: unsafe or failed
    Scouting --> Blocked
    Planning --> Blocked
    Building --> Blocked
    Validating --> Blocked
    Reviewing --> Blocked
    Blocked --> Ready: resolved
    Done --> [*]
    Rejected --> [*]
    RolledBack --> Ready: remediation planned

A transition should occur through deterministic board code whenever possible. Agents recommend transitions and attach evidence; policy decides whether the transition is allowed.

6. General-Purpose Agent Roster

The recommended factory uses eight stable roles plus an elastic builder pool. These roles are project-agnostic. Their specialization comes from task context and dynamically loaded skills.

6.1 Factory Director / Orchestrator

Purpose: Own project lifecycle and Kanban integrity.

Responsibilities:

• Create or select the project board.

• Convert user intent into intake objects.

• Enforce brainstorming and approval boundaries.

• Classify risk and choose workflows.

• Decompose approved projects into epics and tasks.

• Link dependencies and assign workers.

• Monitor stale, blocked, failed, or contradictory tasks.

• Reconcile agent claims against actual evidence.

• Escalate only decisions that require the project owner.

• Never implement large tasks directly when a bounded worker should own them.

Core skills: hermes-agent, agent-orchestration, hermes-kanban-ops, kanban-execution-governance, workflow-policy-overrides, brainstorming, writing-plans.

6.2 Idea and Discovery Agent

Purpose: Turn an idea into a well-understood opportunity or problem.

Responsibilities:

• Ask one focused question at a time.

• Research users, domain, constraints, competitors, prior art, and feasibility.

• Distinguish assumptions from confirmed facts.

• Produce opportunity briefs and research evidence.

• Recommend a spike when feasibility is uncertain.

• Avoid architecture or implementation before the problem is understood.

Core skills: ideation, brainstorming, spike, arxiv, blogwatcher, youtube-content, llm-wiki, maps, polymarket, and other project-selected research skills.

6.3 Scout / Context Engineer

Purpose: Build a bounded context package for planning or debugging.

Responsibilities:

• Inspect project structure, files, documentation, history, open tasks, and existing decisions.

• Search session history and memory only for relevant prior context.

• Inspect connected systems through MCP or APIs.

• Identify conflicting instructions and stale assumptions.

• Return paths, interfaces, constraints, test commands, and unknowns.

• Never claim current external truth from memory when the live source is accessible.

Core skills: codebase-inspection, documentation-engineering, github-operations, native-mcp, mcp-oauth-bridge, browser-session-access, authenticated-browser-capture.

6.4 Architect / Planner

Purpose: Convert context into an approved design and executable task graph.

Responsibilities:

• Propose two or three viable approaches and trade-offs.

• Define architecture, interfaces, data flow, failure behavior, security, testing, rollout, and non-goals.

• Write versioned design documents.

• Decompose work into small dependency-aware tasks.

• Assign validation and evidence requirements before building starts.

• Identify which steps belong to humans, agents, or deterministic code.

Core skills: brainstorming, writing-plans, plan, architecture-diagram, documentation-engineering, design-md, database-contract-delivery, secure-provider-boundaries.

6.5 Elastic Generalist Builder Pool

Purpose: Implement one bounded Kanban task in isolation.

Builders are structurally identical. The router clones or launches as many as the project allows and gives each one a task-specific skill bundle.

Responsibilities:

• Work only inside the task's ownership boundary.

• Follow strict test-first development where applicable.

• Keep changes small and reviewable.

• Run prescribed deterministic checks.

• Attach actual output and changed artifacts to the task.

• Block rather than guess when required context is missing.

• Never self-approve high-risk side effects.

Baseline skills: kanban-worker, test-driven-development, isolated-feature-delivery, systematic-debugging, simplify-code.

Dynamic examples:

• Web frontend: responsive, prototype, accessibility, visual-acceptance skills

• Backend/API: request-boundary, provider-boundary, database-contract skills

• Infrastructure: GitOps, AKS, container, rollout skills

• Data/ML: Jupyter, DSPy, evaluation, W&B, model-serving skills

• Creative: design, infographic, animation, media-generation skills

• Documents: documentation, PDF, DOCX, PowerPoint, XLSX skills

• Productivity: Google Workspace, Notion, Airtable, Linear skills

6.6 Verification / Test Agent

Purpose: Verify the artifact independently using executable evidence.

Responsibilities:

• Run formatting, linting, type checking, unit, integration, contract, security, build, and end-to-end checks as applicable.

• Inspect runtime behavior rather than only source code.

• Capture screenshots, videos, logs, structured reports, and read-back evidence.

• Verify negative paths and regression boundaries.

• Return exact failing commands and evidence to the builder.

• Never rewrite acceptance criteria to make a failure pass.

Core skills: test-driven-development, dogfood, frontend-acceptance-delivery, design-implementation-review, authenticated-browser-capture, canonical-input-validation, typescript-ast-regression-guards.

6.7 Reviewer / Risk Agent

Purpose: Provide an independent judgment after deterministic verification.

Responsibilities:

• Compare the artifact with the approved design and task criteria.

• Review correctness, maintainability, security, scope discipline, tests, and rollback readiness.

• Ensure evidence came from the correct environment.

• Inspect untrusted boundaries, data migrations, auth, secrets, and public exposure.

• Approve for the next gate, request focused changes, or block with evidence.

Core skills: requesting-code-review, secure-provider-boundaries, untrusted-javascript-boundaries, http-request-boundaries, secure-rich-content-pipelines, database-contract-migrations, design-implementation-review.

6.8 Release / Operations Agent

Purpose: Move approved artifacts through hosted environments and verify them live.

Responsibilities:

• Confirm exact artifact, revision, environment, and approval scope.

• Apply migrations, secrets, deployments, and routing in the correct order.

• Monitor rollout and runtime health.

• Verify the live system with IDs, URLs, logs, screenshots, or database read-backs.

• Roll back when hard acceptance checks fail.

• Preserve a release evidence package.

Core skills: approval-gated-hosted-rollouts, github-operations, github-actions-gitops-validation, azure-kubernetes-gitops, webhook-subscriptions, platform-specific operations skills.

6.9 Documentation and Knowledge Curator

Purpose: Keep project and factory knowledge current without polluting global memory.

Responsibilities:

• Update canonical project documentation from actual implementation evidence.

• Produce architecture, operating, API, onboarding, and release documentation.

• Record stable decisions and known risks.

• Promote reusable procedures into skills after approval.

• Patch skills when a proven workflow exposes missing or incorrect instructions.

• Keep temporary task state in Kanban or sessions, not persistent memory.

Core skills: documentation-engineering, knowledge-base-handoffs, hermes-agent-skill-authoring, notion, pdf, docx, powerpoint, xlsx.

6.10 Incident / Hotfix Agent

Purpose: Restore service quickly through a narrow, evidence-driven emergency workflow.

This can initially be an on-demand mode rather than a permanent profile.

Responsibilities:

• Gather logs, traces, deployment history, and impact.

• Form the smallest plausible repair hypothesis.

• Avoid opportunistic refactoring.

• Produce one or more isolated candidate fixes when urgency justifies parallel compute.

• Require human approval before production mutation.

• Open follow-up tasks for root-cause remediation and technical debt.

Core skills: systematic-debugging, approval-gated-hosted-rollouts, observability and platform operations skills.

7. Agent Topology

flowchart TD
    U[Project Owner] <--> D[Factory Director]
    D <--> K[(Project Kanban)]
    D --> I[Idea / Discovery]
    D --> S[Scout]
    D --> P[Architect / Planner]
    P --> K
    K --> B1[Builder 1]
    K --> B2[Builder 2]
    K --> BN[Builder N]
    B1 --> Q[Verification Agent]
    B2 --> Q
    BN --> Q
    Q --> R[Reviewer / Risk Agent]
    R --> D
    D --> O[Release / Operations]
    O --> V[Live Verification]
    V --> K
    K --> C[Documentation / Knowledge Curator]
    A[Incident Trigger] --> H[Incident / Hotfix Agent]
    H --> Q

Persistent versus elastic roles

8. Skill Architecture

Hermes currently exposes approximately 140 discoverable skills in this profile. The factory should not load them all. It should use a three-layer skill model.

8.1 Layer 1: Factory foundation

These skills define how the factory itself operates:

8.2 Layer 2: Cross-cutting quality packs

These are loaded according to risk and artifact type.

Security pack

• canonical-input-validation

• secure-provider-boundaries

• untrusted-javascript-boundaries

• http-request-boundaries

• secure-rich-content-pipelines

• typescript-ast-regression-guards

Data and database pack

• database-contract-delivery

• database-contract-migrations

• supabase-database-delivery

• supabase-auth-debugging

• containerized-postgres-restore

Frontend and product pack

• responsive-frontend-delivery

• frontend-acceptance-delivery

• prototype-driven-frontend-realignment

• html-prototype-to-db-driven-frontend

• design-baseline-realignment

• design-implementation-review

• terminal-modal-ui

Hosted delivery pack

• approval-gated-hosted-rollouts

• github-actions-gitops-validation

• azure-kubernetes-gitops

• azure-aks-startup-onboarding

• azure-dev-stack-power-management

• lan-web-service-access

Evidence and authenticated-browser pack

• authenticated-browser-capture

• authenticated-browser-profile-automation

• browser-session-access

• computer-use

• dogfood

Documentation and artifact pack

• documentation-engineering

• notion

• google-workspace

• pdf

• docx

• powerpoint

• xlsx

• ocr-and-documents

• architecture-diagram

• excalidraw

8.3 Layer 3: Domain plug-ins

These skills let the same general-purpose factory produce different kinds of outcomes.

8.4 Skill selection policy

flowchart TD
    T[Kanban Task] --> C{Classify artifact and risk}
    C --> F[Load factory foundation]
    C --> Q[Load required quality pack]
    C --> D[Load domain plug-ins]
    F --> X[Construct bounded worker context]
    Q --> X
    D --> X
    X --> W[Run worker]
    W --> L{New reusable lesson?}
    L -->|No| E[Attach evidence]
    L -->|Yes| P[Propose skill patch or new skill]
    P --> A{Human approval when creating/deleting}
    A --> E

Rules:

1. Load the smallest skill set that covers the task.

2. Prefer one authoritative workflow skill over several overlapping ones.

3. Project instructions override generic examples when safe.

4. Never load a retired or project-specific skill into unrelated work merely because it exists.

5. Patch a skill when its procedure is proven incomplete or incorrect.

6. Store current task state in Kanban, not skills or persistent memory.

9. Idea-to-Project Lifecycle

Stage 1: Trigger

A user invokes the factory with an idea such as:

“I want to build a system that helps independent clinics schedule staff.”

The trigger may explicitly name the ideation skill, or the Factory Director may detect that the request is creative and route it to the Idea and Discovery workflow.

Stage 2: Create project intake

The Factory Director creates an intake item, but no implementation tasks yet. The item contains the raw statement, source, owner, and initial constraints.

Stage 3: Discovery and clarification

The Idea Agent asks one focused question at a time, researches where appropriate, and produces:

• Problem statement

• Target users

• Desired outcome

• Constraints

• Success measures

• Assumptions

• Risks

• Candidate approaches

Stage 4: Approach selection

Two or three approaches are compared. The owner selects one or requests revision.

Stage 5: Design document

The Architect writes the approved architecture and operating design. The design is versioned and linked to Kanban.

Stage 6: Project activation

After design approval, the Factory Director creates:

• Project board

• Epics

• Child tasks

• Dependency graph

• Agent assignments

• Skill bundles

• Validation policy

• Approval tasks

• Release stages

Stage 7: Plan approval

The owner reviews the complete plan before any task enters Building.

sequenceDiagram
    actor Human as Project Owner
    participant G as Hermes Gateway
    participant D as Factory Director
    participant I as Idea Agent
    participant A as Architect
    participant K as Project Kanban

    Human->>G: Submit idea
    G->>D: Route request
    D->>K: Create intake item
    D->>I: Start discovery workflow
    I->>Human: Ask one focused question
    Human->>I: Provide answer
    I->>K: Attach research and opportunity brief
    I->>Human: Present approaches
    Human->>I: Select or revise approach
    I->>A: Approved problem context
    A->>Human: Present design sections
    Human->>A: Approve design
    A->>K: Link versioned design
    D->>K: Create epics, tasks, dependencies, gates
    D->>Human: Present execution plan
    Human->>D: Approve project activation
    D->>K: Move eligible tasks to Ready

10. Execution Lifecycle

10.1 Routing

The router selects a workflow using deterministic metadata first:

• Task type and labels

• Risk level

• Repository and file ownership

• Required environment

• Dependencies

• Budget

• Urgency

• Existing project policy

An agent classifies only ambiguous cases. A human resolves unresolved intent.

10.2 Context package

The Scout produces a compact package rather than dumping an entire repository into every worker:

• Relevant paths

• Interfaces and dependencies

• Existing patterns

• Tests

• Recent changes

• Known risks

• Explicit unknowns

• Exact source references

10.3 Isolated build

The Builder receives:

Project contract
+ Kanban task
+ approved design excerpt
+ scout context
+ minimal skill bundle
+ tool policy
+ isolated environment
+ validation commands
+ evidence requirements

10.4 Deterministic validation and repair

flowchart LR
    B[Builder Agent] --> F[Formatter]
    F --> L[Linter]
    L --> T[Type Checker]
    T --> U[Unit Tests]
    U --> I[Integration / Contract Tests]
    I --> S[Security / Policy Checks]
    S --> E[E2E / Visual / Runtime Verification]
    F -. failure evidence .-> B
    L -. failure evidence .-> B
    T -. failure evidence .-> B
    U -. failure evidence .-> B
    I -. failure evidence .-> B
    S -. failure evidence .-> B
    E -. failure evidence .-> B
    E -->|all pass| R[Independent Review]

Each repair loop must have a retry limit. When the limit is exhausted, the task becomes Blocked with the most useful evidence preserved.

10.5 Review and release

The Reviewer receives a fresh context containing the approved criteria, diff or artifact, and test evidence—not the builder’s entire persuasive narrative.

After review:

• Low-risk internal artifacts may merge automatically if project policy permits.

• Medium-risk changes normally require human review.

• High-risk and critical changes always require explicit approval.

11. Human, Agent, or Code Decision Framework

flowchart TD
    W[Work step] --> D{Can success be expressed deterministically?}
    D -->|Yes| C[Use code / test / policy]
    D -->|No| A{Does it require synthesis or ambiguity handling?}
    A -->|Yes| G[Use an agent]
    A -->|No| H{Does it require authority, ethics, risk acceptance, or intent?}
    H -->|Yes| P[Use a human gate]
    H -->|No| C
    G --> V[Verify with code where possible]
    V --> H2{High-risk side effect?}
    H2 -->|Yes| P
    H2 -->|No| N[Continue workflow]
    C --> N
    P --> N

Examples

12. Workflow Families

The factory should not force every task through one pipeline.

12.1 Idea / product workflow

Discovery → approaches → design → approval → roadmap → project activation.

12.2 Feature workflow

Scout → plan → approval → TDD build → deterministic QA → review → preview → release approval → deploy → verify.

12.3 Bug workflow

Reproduce → isolate root cause → regression test → minimal fix → full relevant QA → review → deploy → verify original failure path.

12.4 Chore workflow

Lightweight scout → one builder → lint/tests → optional review → merge. Uses cheaper models and fewer gates when safe.

12.5 Research workflow

Question → source plan → retrieval → evidence grading → synthesis → independent fact review → report. No fabricated sources.

12.6 Data workflow

Dataset contract → profiling → transformation → validation → analysis/modeling → reproducible notebook/script → report → artifact registry.

12.7 Creative workflow

Brief → references → two or three concepts → human selection → production → visual/audio QA → export verification.

12.8 Documentation workflow

Source inspection → draft → factual review → link and command verification → render → PDF/HTML visual inspection → publish.

12.9 Infrastructure workflow

Live-state discovery → plan → human approval → isolated or staged change → validation → rollout → health checks → rollback readiness.

12.10 Incident / hotfix workflow

flowchart TD
    A[Alert / Support Incident] --> T[Incident Ticket]
    T --> S[Scout logs, traces, deploy history]
    S --> H[Hotfix Planner]
    H --> G{Human approves proposed repair?}
    G -->|No| H
    G -->|Yes| P[Parallel isolated candidates]
    P --> Q[Deterministic regression and health suite]
    Q -->|fail| P
    Q -->|pass| R[Independent review]
    R -->|reject| P
    R -->|accept| D{Production approval}
    D -->|approved| X[Deploy]
    X --> V[Verify and monitor]
    V -->|failed| RB[Rollback]
    V -->|healthy| C[Close incident and create RCA tasks]

13. Isolation and Concurrency

Isolation progression

1. Single worker, canonical tree: only for simple local work with no concurrency.

2. Git worktree: default for parallel source-code tasks.

3. Container: stronger dependency and process isolation.

4. Remote sandbox or VM: high-risk, long-running, or environment-specific work.

5. Hosted ephemeral environment: scalable factory execution.

Concurrency rules

• A task declares file or subsystem ownership.

• Conflicting tasks cannot run concurrently unless the integration plan explicitly supports it.

• Each worker receives a unique worktree or sandbox identifier.

• Builders do not merge their own output into protected branches.

• Integration is a distinct task with its own validation.

• Parent agents do not assume background subagents survive session termination; durable work belongs on Kanban or in a managed process.

14. Information and Evidence Flow

Every stage should emit a typed artifact.

Evidence invariants

• External side effects require a verifiable handle.

• Screenshots must identify viewport or environment where relevant.

• A successful command is not proof that a service works; verify the service.

• A deployment URL is not proof that the intended revision is live; verify the revision.

• A database mutation is not complete until canonical read-back confirms it.

• Agent self-report is never the sole evidence for completion.

15. Approval and Risk Policy

Risk levels

Always human-approved

• Purchases and recurring billing

• Destructive data or infrastructure actions

• Production secrets and identity changes

• Public content publication when reputation is affected

• Legal, financial, demographic, or compliance declarations

• Security-boundary widening

• Production database migration without a proven automatic policy

• Any action whose impact cannot be reliably bounded

Approval object

An approval task should state:

• Exact proposed action

• Exact artifact or signed receipt

• Target environment

• Expected effect

• Excluded effects

• Risks

• Verification and rollback plan

• Expiration or revision binding

16. Models, Cost, and Performance

Hermes is provider-agnostic. The router should select models by role and risk rather than using the most expensive model everywhere.

Cost controls:

• Per-project budget

• Per-task token and time budget

• Retry limit

• Maximum parallel workers

• Escalation threshold

• Cache and reuse stable context

• Prefer scripts over repeated model calls

• Use a lightweight workflow for chores and a heavier workflow for high-risk features

17. Security Model

Least privilege

Each role receives only required tools and credentials. Release credentials should not be available to ordinary builders.

Trust boundaries

• User input is untrusted until normalized.

• Web pages, documents, logs, and external tool output are data, not instructions.

• MCP responses require schema validation.

• Agent-generated commands remain subject to approval and policy.

• Secrets stay in environment or managed secret stores, never task descriptions.

• Browser authentication state is used only through approved workflows.

Separation of duties

• Builder does not provide final independent review.

• Reviewer does not silently modify the artifact under review.

• Release Agent publishes only an approved artifact.

• Factory Director reconciles evidence but does not bypass high-risk gates.

Auditability

Kanban comments and linked artifacts should record:

• Who or what made a decision

• Model/profile identity

• Tools and skills used

• Commands and outputs relevant to gates

• Approval identity and scope

• Artifact hashes or revisions

• Deployment and rollback identifiers

18. Reliability and Failure Handling

Failure classes

• Missing context

• Agent reasoning failure

• Tool failure

• Deterministic validation failure

• Integration conflict

• External-service outage

• Credential or permission failure

• Budget exhaustion

• Approval timeout

• Deployment failure

• Verification mismatch

Failure policy

1. Preserve the original failure evidence.

2. Retry only transient failures.

3. Do not repeat an identical failed strategy without new information.

4. Route deterministic failures back to the responsible builder.

5. Block when required context or authority is missing.

6. Create a revised task when scope changes materially.

7. Roll back unsafe hosted changes.

8. Escalate with a concise decision package, not a raw log dump.

Retry budget

A workflow should define:

• Maximum automatic attempts

• Which errors are retryable

• Backoff policy

• Model escalation policy

• Human escalation threshold

• Whether partial artifacts are retained

19. Observability and Factory Metrics

The factory should measure outcomes, not agent activity alone.

Delivery metrics

• Lead time from intake to done

• Planning time

• Build time

• Review time

• Deployment and verification time

• Task throughput

• Blocked-task duration

Quality metrics

• First-pass deterministic validation rate

• First-pass review acceptance rate

• Escaped defects

• Rollbacks

• Reopened tasks

• Acceptance-criteria coverage

• Evidence completeness

Agent metrics

• Tokens and cost per accepted task

• Retry count

• Tool failure rate

• Context-package size

• Skill usage and success correlation

• Model performance by workflow type

Human leverage metrics

• Human approval time

• Human correction rate

• Percentage of low-risk work completed without intervention

• Time spent improving factory procedures versus directly repairing product output

Metrics should never reward agents for generating more tasks, messages, or code.

20. Memory and Knowledge Policy

Persistent memory stores

Only stable, high-value facts:

• User preferences

• Long-lived project conventions

• Stable environment boundaries

• Repeated corrections

Session history

Stores what happened in prior conversations and is searched when historical context is needed.

Skills

Store reusable procedures: how to perform a task safely and verify it.

Kanban

Stores current and durable project execution state.

Project documentation

Stores architecture, requirements, runbooks, contracts, decisions, and onboarding material.

Never put in persistent memory

• Current task progress

• Temporary TODOs

• Commit hashes

• PR numbers

• One-time deployment results

• Short-lived incidents

• Raw logs

21. Example: Building an Arbitrary New Product

Suppose the owner says:

“I want to build a mobile and web platform that helps community sports leagues schedule games and communicate with players.”

The factory would:

1. Create a project intake item.

2. Run the Idea Agent to identify users, business model, communication requirements, scheduling complexity, and compliance risks.

3. Present approaches: simple scheduler, league-management platform, or communications-first MVP.

4. Obtain the owner’s selection.

5. Write an approved product and architecture specification.

6. Create a dedicated Kanban board.

7. Decompose the MVP into product, data model, backend, web, mobile, notifications, deployment, documentation, and QA epics.

8. Route each task to elastic builders with different skill bundles.

9. Run deterministic validation and independent review.

10. Deploy preview environments.

11. Obtain release approval.

12. Verify the live product at relevant device sizes and API boundaries.

13. Update project documentation and reusable skills.

The permanent agent roster stays the same. Only project context, tools, skills, and task graph change.

22. Maturity Roadmap

Phase 0 — Design and governance

• Approve this architecture.

• Define project and task schemas.

• Define risk and approval policy.

• Define evidence contracts.

• Choose initial agent profiles.

Phase 1 — Assisted single-project workflow

Human → Factory Director → one Builder → deterministic checks → Reviewer → Human

• One board

• One project

• No automatic dispatch

• Human approval before build and release

• Strict evidence collection

Phase 2 — Kanban-driven general factory

• Project creation workflow

• Durable dispatcher

• Stable general-purpose profiles

• Skill router

• Worktree isolation

• Dependency-aware execution

• Independent verification and review

Phase 3 — Parallel and event-driven execution

• Multiple isolated builders

• Webhook-triggered tasks

• CI and monitoring integration

• Preview environments

• Automatic repair loops with budgets

• Specialized bug, feature, chore, and document workflows

Phase 4 — Adaptive software factory

• Workflow selection based on measured reliability

• Model and compute routing

• Ephemeral sandboxes

• Parallel candidate solutions for selected work

• Reduced human gates for proven low-risk workflows

• Automatic rollback and incident activation

Phase 5 — Organization-scale factory

• Multiple project boards

• Shared factory policy with project-specific overrides

• Portfolio-level prioritization

• Cross-project dependency visibility

• Cost, quality, and human-leverage analytics

• Formal governance and audit retention

The factory should not advance phases until the previous phase demonstrates reliable outcomes.

23. Recommended Initial Agent Profiles

If implemented later, the recommended first profile set is:

factory-director
factory-discovery
factory-scout
factory-architect
factory-builder
factory-verifier
factory-reviewer
factory-release
factory-curator

factory-builder is cloned or spawned elastically. factory-incident can be introduced after ordinary feature and bug workflows are reliable.

Profile baseline

Every profile should define:

• Role and explicit non-role

• Allowed toolsets

• Default model class

• Skill baseline

• Kanban permissions

• Filesystem or sandbox boundary

• External credentials

• Approval authority

• Evidence contract

• Time and retry limits

• Escalation behavior

24. Recommended First Workflow

The first productionized factory workflow should be intentionally narrow:

flowchart LR
    T[Approved Kanban Task] --> S[Scout]
    S --> P[Planner]
    P --> H1{Human plan approval}
    H1 -->|revise| P
    H1 -->|approve| B[Isolated Builder]
    B --> Q[Deterministic QA]
    Q -->|fail| B
    Q -->|pass| R[Independent Reviewer]
    R -->|changes| B
    R -->|accept| H2{Human merge/release approval}
    H2 -->|approve| D[Preview or UAT deploy]
    D --> V[Live verification]
    V -->|fail| B
    V -->|pass| C[Kanban Done + documentation]

Recommended constraints:

• One repository

• One task at a time initially

• No production deployment

• Human approval before implementation

• Human approval before merge

• At least one deterministic test gate

• Independent reviewer

• Evidence attached to Kanban

After this is repeatable, introduce parallel builders and specialized workflow families.

25. Key Architectural Decisions

1. Kanban is project-scoped and authoritative for execution.

2. Projects are isolated by board, work directory, policy, and evidence.

3. The factory uses general roles plus dynamic skills, not hundreds of permanent agents.

4. Builders are elastic and isolated.

5. Verification and review are separate from implementation.

6. Deterministic code owns pass/fail whenever possible.

7. Humans own intent and high-risk approval.

8. External actions require read-back or equivalent proof.

9. Skills encode reusable procedures; Kanban stores current work.

10. Autonomy expands only after measured reliability.

26. Open Decisions Before Implementation

These questions must be resolved during a future implementation design phase:

1. Should every new idea automatically create a board, or should board creation require concept approval?

2. Which profile hosts the Factory Director?

3. Should project boards live under the default profile or a dedicated factory profile?

4. Which Kanban statuses and metadata fields require Hermes changes versus conventions?

5. Which initial project will serve as the factory pilot?

6. What maximum number of concurrent builders is acceptable?

7. Which actions may be self-approved for low-risk work?

8. Which evidence store should hold large screenshots, videos, and reports?

9. Which sandbox technology should follow Git worktrees?

10. Which model classes and budgets should be assigned to each role?

11. How long should task and approval audit records be retained?

12. What reliability threshold permits reducing a human gate?

No implementation should begin until these decisions are designed and approved.

27. Conclusion

A general-purpose Hermes software factory should not be designed as one autonomous super-agent. It should be designed as an observable project operating system.

The project owner supplies purpose and authority. The Kanban board supplies durable coordination. General-purpose Hermes roles supply reasoning and execution. Skills supply reusable specialization. Deterministic code supplies reliability. Sandboxes supply isolation. Evidence supplies trust. Human gates supply accountability.

The result is a system capable of turning many kinds of ideas into verified outcomes without coupling the factory to Omizi WMS, a portfolio, a particular programming language, or even software alone.

The goal is not to eliminate engineering. The goal is to move engineering up one layer: from repeatedly performing every task to designing, governing, and improving the system that performs those tasks reliably.

Appendix A — Available Skill Families

The current Hermes profile exposes roughly 140 discoverable skills across these families:

• Autonomous agents and Hermes operation

• Brainstorming and ideation

• Software development and testing

• GitHub and codebase inspection

• DevOps, Kubernetes, GitOps, and hosted rollout

• MCP and external-system integration

• Productivity and document creation

• Research and knowledge management

• Data science and notebooks

• MLOps, model evaluation, serving, and experimentation

• Creative design, diagrams, animation, audio, and media

• Browser automation and authenticated capture

• Email and collaboration tools

• Project-specific specialist procedures

Project-specific skills should not become factory defaults. They are loaded only when the project or task matches their scope.

Appendix B — Factory Skill Bundle Templates

Concept bundle

ideation
brainstorming
spike
relevant research skills

Planning bundle

codebase-inspection
documentation-engineering
writing-plans
architecture-diagram
security or database design skills when relevant

General implementation bundle

kanban-worker
test-driven-development
isolated-feature-delivery
systematic-debugging
simplify-code

Web product bundle

responsive-frontend-delivery
frontend-acceptance-delivery
design-implementation-review
dogfood
authenticated-browser-capture

API and data-boundary bundle

canonical-input-validation
http-request-boundaries
secure-provider-boundaries
database-contract-delivery
database-contract-migrations

Parallel delivery bundle

worktree-parallel-development
parallel-tdd-delivery
subagent-driven-development
kanban-execution-governance

Release bundle

requesting-code-review
github-operations
approval-gated-hosted-rollouts
github-actions-gitops-validation
platform operations skill

Documentation bundle

documentation-engineering
architecture-diagram
pdf
docx
powerpoint
notion or google-workspace

AI / ML bundle

jupyter-live-kernel
dspy
evaluating-llms-harness
weights-and-biases
huggingface-hub
model-serving skill when applicable

Appendix C — Definition of Done Template

A task is done only when:

• Its approved acceptance criteria are satisfied.

• Changes stay within declared scope.

• Required deterministic checks pass.

• Independent review is complete.

• Required human approvals are recorded.

• External side effects have verifiable handles.

• Live or rendered behavior is verified where applicable.

• Rollback or recovery expectations are documented.

• Kanban contains evidence links and final disposition.

• Project documentation is updated.

• Reusable workflow lessons are proposed as skill improvements when appropriate.

Appendix D — Source Inspiration

• IndyDevDan, “FORGET Loop Engineering. Agentic Engineering is about THIS”, YouTube, video ID VQy50fuxI34, 34:19.

• Hermes Agent capabilities: profiles, skills, delegation, Kanban, webhooks, cron jobs, MCP integrations, memory, browser automation, deterministic terminal execution, and multi-platform gateway operation.