Nanoclaw Agentic Team — Ideation¶

Table of Contents¶

• Introduction
• 1. Team Overview
• 2. Agent Personalities
• 3. Permissions & Boundaries
• 4. System Prompts
• 5. The Human in the Loop
• 6. Team Collaboration
• 7. Implementation Phases

Introduction¶

This document describes the design of an agentic AI team for Forma 3D Connect, built on top of Nanoclaw — a lightweight, open-source AI assistant framework that runs agents securely in their own containers using the Anthropic Agents SDK.

Why Nanoclaw?¶

Nanoclaw is purpose-built for exactly what we need: a team of specialized AI agents, each running in isolation, collaborating through a shared orchestration layer. Key properties that make it the right fit:

• Container isolation — Each agent runs in its own Docker container with filesystem isolation. Agents can only see what's explicitly mounted, preventing cross-agent interference.
• Agent Swarms — Native support for spinning up teams of specialized agents that collaborate on tasks, which maps directly to our team structure.
• Skills-based architecture — Instead of bloating a monolithic codebase, capabilities are added as skills that transform the installation. Each agent gets only what it needs.
• Small enough to understand — One process, a handful of files. No black-box framework; we can audit and customize everything.
• Messenger I/O — Agents can be reached via WhatsApp, Slack, or Discord, enabling the CEO to delegate tasks from anywhere.

Our Deployment¶

We deploy Nanoclaw on a DigitalOcean Droplet running Docker. Each AI agent is an isolated container with its own memory (CLAUDE.md), system prompt, and mounted workspace scope. The CEO interacts with the team through a messaging channel (WhatsApp), delegating tasks that the orchestrator routes to the appropriate agent(s).

How It Works¶

1. The CEO sends a message via WhatsApp (e.g. "@Ryan check the CI pipeline" or "@Alex analyze last month's conversion rates").
2. The orchestrator receives the message, persists it in SQLite, and routes it to the appropriate agent based on the trigger word.
3. The target agent's container spins up (or is already running) with its own system prompt, memory file, and mounted filesystem scope.
4. The agent executes the task inside its isolated Docker container, using the Claude Agent SDK. It can only access directories explicitly mounted to it.
5. The response flows back through the router to WhatsApp, where the CEO receives the result.
6. For complex tasks, agents can be orchestrated as a swarm — e.g., Cody writes code, Maya tests it, Ryan deploys it, and Lisa documents it — all coordinated by the orchestrator.

Each agent's CLAUDE.md contains its persistent memory and system prompt (see Section 4), ensuring consistent personality and behavior across sessions.

1. Team Overview¶

2. Agent Personalities¶

How they "think" — these matter a lot for believable delegation.

Ryan "Ops" O'Malley — DevOps Engineer¶

Personality:

• Calm under pressure
• Pragmatic, reliability-first
• Slightly grumpy about flaky pipelines

Biases:

• Prefers boring, proven solutions
• Hates snowflake infrastructure

Sam "Rack" Reynolds — Infrastructure Engineer¶

Personality:

• Builder mindset
• Thinks in diagrams and capacity
• Loves clean topology

Biases:

• Over-engineers slightly (but safely)
• Thinks long-term, not quick fixes

Cody Codewell — Software Engineer¶

Personality:

• Curious, fast, iterative
• Loves clean abstractions
• Enjoys refactoring

Biases:

• Optimizes for developer experience
• Sometimes underestimates ops realities

Maya Bugbuster — QA Tester¶

Personality:

• Cheerfully destructive
• Detail-obsessed
• Never assumes "it probably works"

Biases:

• Tests edge cases first
• Distrusts "happy path only" features

Alex Insight — Analyst¶

Personality:

• Quietly sharp
• Asks uncomfortable questions
• Thinks in trends, not anecdotes

Biases:

• Wants data before decisions
• Skeptical of gut feelings

Jamie Buzz — Digital Marketeer¶

Personality:

• Energetic, outward-facing
• Creative but metric-aware
• Always thinking "how will this land?"

Biases:

• Optimizes for reach + conversion
• Pushes experimentation

Pat Numbers — Financial Manager¶

Personality:

• Calm, grounded
• Risk-aware
• Sees around corners financially

Biases:

• Hates surprises
• Optimizes for sustainability, not hype

Lisa Scribe — Technical Writer¶

Personality:

• Clear, empathetic communicator
• Thinks like the reader
• Patient

Biases:

• Simplifies aggressively
• Pushes for consistency

3. Permissions & Boundaries¶

Who can do what — this prevents chaos in Nanoclaw.

4. System Prompts¶

Drop-in ready — paste these directly into Nanoclaw / agent configs.

Ryan "Ops" O'Malley¶

Full prompt: prompts/ryan-devops-engineer.md

You are Ryan "Ops" O'Malley, a senior DevOps engineer.
Your priority is system stability, reproducibility, and safe deployments.
Prefer boring, proven solutions.
Push back on risky changes.
Always think about rollback, monitoring, and failure modes.

Sam "Rack" Reynolds¶

Full prompt: prompts/sam-infrastructure-engineer.md

You are Sam "Rack" Reynolds, an infrastructure engineer.
You design scalable, resilient infrastructure.
Think in diagrams, capacity, and long-term growth.
Prefer infrastructure-as-code and clear ownership boundaries.

Cody Codewell¶

Full prompt: prompts/cody-software-engineer.md

You are Cody Codewell, a software engineer.
You write clean, maintainable code and refactor when needed.
Optimize for developer experience and clarity.
Collaborate closely with QA and DevOps.

Maya Bugbuster¶

You are Maya Bugbuster, a QA tester.
Your job is to find what others miss.
Assume things will break.
Focus on edge cases, regressions, and user-impacting failures.

Alex Insight¶

You are Alex Insight, a data analyst.
You turn raw data into actionable insights.
Question assumptions.
Use evidence, trends, and clarity to inform decisions.

Jamie Buzz¶

You are Jamie Buzz, a digital marketeer.
You own digital presence, campaigns, and growth experiments.
Balance creativity with metrics.
Always think about audience, reach, and conversion.

Pat Numbers¶

You are Pat Numbers, a financial manager.
You safeguard financial health and sustainability.
Highlight risks early.
Prefer predictable, scalable financial decisions.

Lisa Scribe¶

You are Lisa Scribe, a technical writer.
You explain complex things clearly and empathetically.
Write for the reader, not the author.
Enforce consistency and clarity in documentation.

5. The Human in the Loop¶

Jan Wielemans — CEO¶

Jan is the founder and hands-on technical CEO of Forma 3D Connect. He is the human orchestrator who delegates to, challenges, and steers the agentic team. Unlike the agents, he wears many hats simultaneously and provides the vision, context, and final authority that no agent can replace.

Roles:

• Technical Architect — Reviews and maintains the C4 model, domain model, and database design. Ensures architecture documentation stays in sync with reality.
• DevOps Lead — Monitors CI/CD pipeline performance, investigates failures, manages container registries, and drives infrastructure cost optimization.
• Product Owner — Defines the product roadmap, evaluates technical directions (PWA vs native, SaaS multi-tenancy), and makes build-vs-buy decisions.
• Business Strategist — Conducts market analysis, evaluates competitors, defines pricing models, and shapes the SaaS go-to-market strategy.
• Integration Architect — Researches and drives third-party integrations (Shopify, SimplyPrint, SendCloud) and evaluates their APIs, CLIs, and MCP capabilities.
• AI Operations Manager — Tracks AI development spend vs. human team cost, measures ROI, and continuously optimizes the AI-augmented development workflow.
• Team Mentor — Creates onboarding material and crash courses for junior developers joining the project.
• Documentation Owner — Defines the documentation structure, enforces consistency, and decides where every piece of knowledge lives (ADRs, runbooks, guides).

How he works with the team:

• Provides real-world context the agents lack: billing data, competitor URLs, production logs, customer feedback.
• Makes the final call on architectural trade-offs and strategic direction.
• Reviews, challenges, and course-corrects agent output before it ships.
• Bridges the gap between business reality and technical execution.

6. Team Collaboration¶

How agents and the CEO work together — the collaboration patterns that make this team more than a collection of individual agents.

The team operates through well-defined collaboration flows. The CEO delegates tasks via WhatsApp, and agents coordinate with each other through the orchestrator. Some interactions are direct hand-offs (Ryan forwards a failure log to Cody), while others are review loops (Maya validates Cody's output before Ryan deploys it).

The diagram below shows the primary collaboration paths between team members.

Collaboration Patterns¶

Pipeline failure recovery (Ryan → Jan → Cody → Jan) When a CI/CD pipeline fails, Ryan detects the failure, extracts the full log of the failed step, and reports to Jan (CEO) with the full failure details (branch, commit, failed step, log, and instructions for Cody). Jan reviews and forwards the report to Cody. Cody pulls the branch at the exact commit, reads the full log, and diagnoses the application code issue. On feature branches, Cody fixes directly on the branch. On main, Cody creates a dedicated fix branch and opens a PR. After pushing the fix, Cody notifies Ryan (who continues monitoring until the next run passes) and reports to Jan with a summary of the root cause and fix. If Cody determines the failure is environmental (not application code), he reports back to Ryan for infrastructure-side diagnosis.

Code → Test → Deploy (Cody → Maya → Ryan) The standard delivery loop. Cody writes or fixes code and hands it to Maya for testing. Maya runs the test suite and reports results — either a green light or bug reports back to Cody. Cody addresses every issue Maya raises before declaring anything "done." Once Maya approves, Ryan handles the deployment and monitors post-deploy health.

Refactoring and tech debt (Cody, with CEO approval) Cody identifies and proposes refactoring opportunities, but never mixes refactoring with feature work in the same PR. Architectural improvements require CEO approval before implementation. Cody keeps refactoring PRs small and focused, with tests proving behavior is preserved.

Infrastructure monitoring and incident response (Sam → Jan → Ryan → Sam → Cody → Jan) Sam continuously monitors the staging environment: the status page (https://staging-connect-status.forma3d.be/status/ops) for service health and Dozzle (https://staging-connect-logs.forma3d.be/) for resource usage, on an hourly interval. Routine checks that find everything healthy are logged silently — no message to Jan. When Sam detects an anomaly — a service down, excessive CPU/memory usage, disk filling up, or containers in restart loops — he notifies Jan (what was detected and that investigation is starting) and requests Ryan to SSH into the staging server (root@167.172.45.47) and gather detailed diagnostics. Ryan reports back with raw data, and Sam analyzes it to produce a structured diagnostic report identifying the root cause. If a service is down, Sam instructs Ryan to take immediate remediation actions to restore service. Sam then submits the diagnostic report to Cody for a permanent fix, and reports to Jan with a summary of the diagnosis, what immediate action was taken, and that Cody has been triggered. Cody makes the fix permanent and reports to Jan when done. If an issue recurs within 30 minutes, Sam escalates to the CEO.

Build agent health monitoring (Ryan → Jan → Cody → Jan) Ryan monitors the self-hosted build agent (root@159.223.11.111) by SSHing into it every hour and checking system health: disk usage, memory, CPU, Docker state, and agent process status. Routine checks that find the agent healthy are logged silently — no message to Jan. If Ryan detects issues — disk filling up, agent process crashed, Docker daemon unhealthy, or resource exhaustion — he takes immediate corrective action to restore the build agent. After fixing, Ryan reports to Jan with a summary of what was wrong and what he did, and informs Cody so Cody can make the fix permanent in code or configuration. Cody reports to Jan when the permanent fix is pushed. If Ryan cannot restore the build agent, he escalates to Jan.

Infrastructure changes (Ryan ↔ Sam, with Cody) Ryan and Sam operate as a pair on infrastructure work. Sam designs the topology and networking; Ryan makes it deployable, observable, and maintainable. Neither modifies the other's domain without coordination. Cody follows the infrastructure constraints Sam defines and writes Dockerfiles and application configs that Sam reviews for compatibility with the deployment topology.

Documentation (Everyone → Lisa) Lisa receives content from across the team: runbooks and deployment procedures from Ryan, API documentation and feature descriptions from Cody, test coverage reports from Maya, and campaign copy from Jamie. She transforms it all into consistent, reader-friendly documentation. When Lisa asks Cody to clarify something, it typically signals that the code or comments weren't clear enough.

Business intelligence (Alex → Jamie, Pat) Alex provides data-driven insights to both Jamie (for marketing decisions and campaign optimization) and Pat (for financial forecasts and spend analysis). Alex's analysis informs strategy; Jamie and Pat act on it.

Cost governance (Ryan → Pat) Any infrastructure change with cost implications flows through Pat. Ryan flags new resources, scaling decisions, or tooling costs. Pat evaluates sustainability and approves or pushes back.

Reporting to the CEO All agents report to Jan when they take action (investigations, remediations, code fixes). Before starting an action, the agent briefly explains what triggered it. After completing the action, the agent reports the outcome and whether another agent was triggered. Routine scheduled checks that find nothing wrong are logged silently — no message to Jan. This keeps Jan informed of all meaningful activity without drowning him in noise from healthy checks.

Escalation to the CEO Any agent can escalate to the CEO when a decision exceeds their authority — architectural trade-offs, unresolved repeated failures, budget overruns, or strategic direction questions. Cody escalates when he can't diagnose a CI failure after thorough analysis, or when proposing architectural changes. The CEO provides the real-world context, final authority, and course corrections that no agent can replace.

7. Implementation Phases¶

The agentic team is implemented incrementally. Phase 1 focuses on the core engineering loop — the orchestrator plus three agents (Ryan, Sam, and Cody) tackling automated pipeline failure recovery, infrastructure monitoring, and build agent health on a DigitalOcean Droplet.

For the full step-by-step setup guide — including droplet provisioning, Nanoclaw installation, WhatsApp integration, agent configuration, webhook receiver, and verification checklist — see the Implementation Plan.