Frequently Asked Questions About Solmaz On-Demand Disposable Agent Orchestration Framework
23 answers covering everything from basics to advanced usage.
// Basics
What is an agent harness?
A harness is the full coding agent environment wrapping an AI model — including context, tooling, and integration layer. Examples include Codex, Claude Code, and OpenClaw. A harness is distinct from the model itself; it's the operational shell that lets the model actually do work. In this framework, harnesses are made interchangeable through ACP adapters.
What does 'on-demand disposable agent' actually mean?
It means every task gets its own ephemeral agent instance running in a dedicated Kubernetes pod, spun up when the task arrives and torn down when it completes. This is deliberately wasteful in resource terms, but it's the better abstraction — giving a full computer to an agent is dramatically more powerful than constraining it to a limited sandbox.
What is the fire hose problem?
The fire hose is a high-volume, continuous stream of inbound work items — PRs, issues, bug reports — that exceeds any human's capacity to process manually. It's the core problem this framework absorbs. When your inbound work is repetitive enough to automate but nuanced enough to need agent judgment, the fire hose is your signal to deploy orchestrated agents.
What is Standard Operating Procedure for agents?
An SOP for agents is an encoded, reusable workflow defining the exact sequence of steps an agent takes for a repeating task class. Instead of ad-hoc prompting, you build structured, JSON-output-driven loops — review, judge, refactor, relate-to-human — that can be replayed, inspected, and improved. It's the automatable equivalent of what a human expert does repeatedly.
// How To
How do I set up ACPX as my control plane?
Install ACPX and bind your communication platform channels — Discord, Slack, Teams — to specific harnesses through ACP. ACPX becomes your Swiss Army knife CLI where any agent can call any other agent over the command line. Wire your SOP steps as programmatic nodes in its Argo-like workflow engine, with each node emitting structured JSON that feeds the next.
How do I deploy disposable agent pods on Kubernetes?
Give each task one Kubernetes pod as a full compute environment. Use a goal operator — like the Spritz pattern at textcortex/spritz — to handle provisioning, lifecycle, and teardown. Deploy with helm charts for repeatability. Accept the resource cost as the price of the better abstraction. The operator abstracts infrastructure complexity away from the agent user.
How do I design an SOP workflow for a task type?
For each repeating task class, encode an explicit sequence. For PR intake: find intent, judge implementation quality, check for conflicts, verify CI status, run a shallow refactor loop if needed, and relate to a human only if fundamental refactoring is required. Output each decision as structured JSON so it's auditable and pluggable into your workflow engine.
How do I surface agents on Slack or Discord?
Create a single concierge agent that humans talk to. It dispatches on-demand disposable agents for specific tasks and returns a UI link — like an in-cluster React app — when the platform doesn't support multi-agent cosmetic provisioning natively. Never manage agent app manifests by hand; automate all provisioning through the goal operator from day one.
How do I handle low-quality AI-generated PRs?
Never treat AI-generated PR descriptions as ground truth — most inbound PRs have low-signal descriptions, so have the agent independently determine intent before judging implementation. And don't discard slop PRs entirely: even low-quality PRs are crucial user feedback data points indicating where something in the codebase is broken. Categorize and bin them instead.
// Troubleshooting
Why are my parallel agents producing conflicting files?
You're likely missing a state synchronization layer. Agents editing files concurrently need a mechanism to keep file state consistent — grant read/write GitHub access and layer an rsync-style or Dropbox-algorithm sync. Without it, parallel agent pods produce conflicting artefacts silently, which is one of the most damaging and hard-to-detect pitfalls at scale.
Why is my agent producing slop during refactoring?
You're probably using it for design decisions inside a refactor loop. Looping an agent on refactors is safe only for shallow, superficial bugs. Using it to design architecture from scratch produces slop. Distinguish clearly: shallow bugs stay in the loop; fundamental refactors must break out of the loop and escalate back to a human for judgment.
Why is my single agent bottlenecking under load?
One agent instance per platform integration cannot handle 100+ concurrent users — that's the single-instance bottleneck anti-pattern. The correct architecture is the concierge pattern with on-demand disposable agents: a persistent front-door agent that dispatches a fresh disposable pod per task. Each user gets their own full compute environment rather than competing for one shared instance.
Why are instructions getting garbled between my agents?
You're playing the telephone game — routing instructions through a middle-model, like asking Claude to tell Codex what to do, introduces paraphrasing errors. Wording matters enormously when prompting. Use ACP to route directly between the human and the target agent instead of chaining LLMs that paraphrase each other's instructions.
How do I avoid the telephone game when chaining agents?
Don't have one LLM paraphrase instructions to another if you can route directly. Chaining agents by relaying instructions through a middle-model introduces paraphrasing errors because exact wording matters when prompting. Use ACP adapters to standardize communication so harnesses are interchangeable and instructions travel directly from source to target without a lossy paraphrasing hop.
// Comparisons
How does ACP compare to A2A and MCP?
MCP gives tools to the model. A2A handles agent-to-agent communication. ACP standardizes the human-to-agent interface — its key value is write-once, deploy-everywhere, so one adapter works across all compliant harnesses instead of every editor building its own. ACP can also let agents talk to other agents, but its distinct purpose is the human-talking-to-agent layer.
How does this differ from a generic CI/CD bot?
A generic CI/CD bot runs fixed scripts on triggers. This framework runs full AI agents with judgment inside encoded SOPs, each in its own disposable full-compute pod. It doesn't just check boxes — it independently determines PR intent, judges implementation quality, and decides when human escalation is needed, all while staying auditable through structured JSON outputs.
How does disposable pods compare to constrained sandboxes?
Constrained sandboxes limit what an agent can do to reduce risk and cost. Disposable full-compute pods deliberately give each agent an entire computer, which is dramatically more powerful. This framework accepts the resource waste of one full pod per task because the capability gain outweighs the cost — a full environment lets agents solve problems sandboxes can't.
How does ACPX compare to Argo Workflows?
ACPX functions as an Argo-like workflow engine, but instead of orchestrating raw containers as DAG nodes, it drives a Codex or equivalent harness session. Your SOP steps become programmatic nodes, each emitting structured JSON that feeds the next. It borrows Argo's DAG-structured execution model but applies it specifically to agent-driven work.
// Advanced
What is the Ship of Theseus principle for harnesses?
A harness doesn't need to be rebuilt from scratch as requirements evolve — it can be ripped apart and put back together iteratively. The identity of the system is maintained through continuity of use, not continuity of implementation. This lets you evolve your agent environment aggressively without treating any single implementation as sacred.
What is 'automating the automator'?
When you notice yourself repeating the same mechanical judgment steps — reviewing a PR for intent, checking CI, resolving conflicts — that repetition is a signal to encode it as a workflow and hand it to an agent. You're not automating creativity; you're automating the scaffolding around it. Treat your own tool limitations as first-class signals for the next thing to automate.
What are parallel channel workloads and how do I use them?
Instead of one agent per session, run one agent per task channel — for example Codex-1 through Codex-5 in Discord. Each channel is effectively a full IDE session driven by an on-demand agent. Monitor across 1–5 channels simultaneously as a single operator. This compresses elapsed time dramatically and enables coding-on-the-go from any messaging platform.
What is Telegram Driven Development?
Telegram Driven Development (TDD) is a workflow pattern where agent tasks are dispatched, monitored, and iterated via messaging platform channels — Telegram, Discord, Slack — rather than traditional IDEs. It lets a single developer run parallel work across multiple projects from a phone. To retrieve artefacts agents can't send directly, like generated PDFs, use a dedicated channel pointing at a path like /tmp.
Should I apply agents to every problem?
Treat agent capability like an ointment — apply it generously to any problem solvable with agents. The default posture should always be: how do I take myself out of this loop? That said, still respect the boundaries — fundamental design decisions and architectural refactors stay with humans. Apply generously to mechanical and agent-assisted work, not to creative design.