Frequently Asked Questions About Solmaz On-Demand Disposable Agent Orchestration Framework
22 answers covering everything from basics to advanced usage.
// Basics
What is the difference between a harness and a model in agent orchestration?
A harness is the full coding agent environment wrapping an AI model — it includes context management, tooling, file access, and the integration layer. Examples include Codex, Claude Code, and OpenClaw. The model (e.g. GPT-4, Claude) is just the language model inside. When you orchestrate agents, you orchestrate harnesses, not raw models, because the harness determines what the agent can actually do in the real world.
What does 'on-demand disposable' actually mean for agent pods?
Each task gets its own ephemeral Kubernetes pod — a full compute environment with its own filesystem, tools, and runtime. The pod is created when a task arrives and destroyed when it completes. This is resource-wasteful but gives each agent the equivalent of a full computer, which is dramatically more powerful than sharing a constrained sandbox. The Goal Operator automates the entire lifecycle.
How is ACP different from just using an API to talk to an AI agent?
ACP is a protocol that standardises the human-to-agent interface across all compliant harnesses. A raw API ties you to one specific agent's implementation. With ACP, you write one adapter that works with Codex, Claude Code, OpenClaw, or any future ACP-compliant harness. It eliminates the duplicated integration work that happens when each editor or platform builds its own proprietary connection to each agent.
What is Telegram Driven Development (TDD) in this context?
Telegram Driven Development is a workflow pattern where agent tasks are dispatched, monitored, and iterated via messaging platform channels rather than traditional IDEs. You send tasks from your phone via Telegram, Discord, or Slack, and agents execute in on-demand pods. This enables coding-on-the-go — for example, working on multiple side projects via parallel Discord channels while commuting, with each channel bound to a full agent session.
What is the 'apply agents generously' principle?
Treat agent capability like ointment — apply it generously to any problem that can be solved with agents. Your default posture should be: how do I take myself out of this loop? If you find yourself repeating mechanical steps, that's a signal to encode it as an SOP and hand it to an agent. Don't ration agent usage; the cost of an agent pod is almost always less than the cost of your time on mechanical work.
// How To
How do I decide which tasks to automate vs. keep for humans?
Classify inbound work into three buckets: (a) fully automatable mechanical work, (b) agent-assisted work requiring human sign-off, and (c) work requiring human design judgment. Only (a) and (b) enter the agent workflow. The key signal is repetition — if you notice yourself repeating the same mechanical judgment steps, that pattern should be encoded as an SOP. Fundamental design decisions and architectural choices always stay with humans.
How do I set up parallel channel workloads on Discord or Slack?
Create dedicated channels per task — e.g. Codex-1 through Codex-5 in Discord. Bind each channel to a harness session via ACPX. Each channel is effectively a full IDE session driven by an on-demand agent. Monitor across 1-5 channels simultaneously. This enables concurrent task execution from a single human operator and compresses elapsed time dramatically compared to sequential processing.
How do I handle file state synchronisation when running multiple agent pods?
Grant agents read/write GitHub access and layer an rsync-style or Dropbox-algorithm synchronisation mechanism so file state stays consistent across pods. Without this, parallel agents produce conflicting artefacts silently. The sync layer must handle concurrent writes gracefully — treat it as infrastructure, not an afterthought. Configure it during deployment, before you start running parallel workloads.
How do I structure an SOP workflow as JSON output nodes?
Define each step as a node that emits structured JSON. For a PR review SOP: Node 1 outputs {"intent": "..."}, Node 2 outputs {"quality_judgment": "pass|fail", "reasons": [...]}, Node 3 outputs {"conflicts": []}, Node 4 outputs {"ci_status": "..."}, Node 5 either loops for shallow fixes or outputs {"escalate": true, "reason": "..."}. Each node's JSON feeds the next. This makes the workflow auditable, debuggable, and pluggable into ACPX's Argo-like engine.
// Troubleshooting
Why are my agents producing conflicting code changes?
You are likely running parallel agent pods without a state synchronisation layer. Each pod has its own filesystem and doesn't know what other pods have modified. Configure rsync-style or Dropbox-algorithm file synchronisation across all active agent pods. Also check that agents aren't editing the same files simultaneously — use task decomposition to assign non-overlapping file scopes when possible.
My agent keeps making bad architectural decisions in refactor loops — what's wrong?
You are likely using the agent for fundamental refactors instead of shallow bug fixes. Looping an agent on refactors is safe only for superficial bugs — things easily uncovered and fixed without human design input. Fundamental refactors require human judgment and must be escalated out of the loop. Add an explicit check in your SOP: if the refactor touches architecture, break the loop and relate back to a human.
Agent instructions are getting garbled when I chain multiple agents together — how do I fix this?
You're hitting the telephone game anti-pattern. When one LLM paraphrases instructions for another, wording changes introduce errors. Use ACP to route instructions directly to the target harness instead of chaining through intermediary models. If you must compose agents, pass structured JSON between them rather than natural language to minimise paraphrasing drift.
What happens if a disposable agent pod crashes mid-task?
The Goal Operator should handle crash recovery. Configure retry policies in your helm charts and SOP workflows. Because each pod is disposable and task-scoped, a crash affects only one task — not the entire system. The crashed pod is torn down, a new pod is provisioned, and the task restarts from the last checkpoint. Ensure your state synchronisation layer persists progress to GitHub or shared storage so restarts don't lose work.
How do I prevent runaway costs with on-demand disposable pods?
Set Kubernetes resource quotas and limits per namespace. Configure pod timeouts so agents that hang are terminated automatically. Use the Goal Operator's teardown lifecycle to ensure pods don't linger. Monitor pod counts and compute usage with standard Kubernetes observability tools. Accept that the per-task resource cost is higher than shared sandboxes, but the total cost is justified by the dramatic reduction in human mechanical labor and elapsed time.
// Comparisons
How does the Solmaz framework compare to using Argo Workflows directly?
Argo Workflows orchestrates raw containers and scripts. The Solmaz framework uses ACPX as an Argo-like workflow engine that drives AI agent harness sessions — it adds the agent intelligence layer on top. Each node isn't just running a script; it's running a full AI coding agent that exercises judgment. You also get ACP standardisation, concierge dispatch, and disposable pod lifecycle management that Argo alone doesn't provide.
How does disposable agent orchestration compare to using GitHub Actions for automated PR review?
GitHub Actions runs static scripts and pre-defined checks. Disposable agent orchestration runs full AI coding agents that can understand intent, judge implementation quality, perform refactors, and make nuanced decisions. Actions are rule-based; agent orchestration is judgment-based. The Solmaz framework also scales across platforms (not just GitHub), runs parallel agents per task, and uses SOPs that evolve with the codebase.
How does ACP compare to just building a custom Slack bot for each agent?
Custom Slack bots tie you to one platform and one agent. ACP standardises the human-to-agent interface so one adapter works across Slack, Teams, Discord, and all ACP-compliant harnesses. When you switch from Codex to Claude Code, you don't rebuild the bot. When you add Teams support, you write one adapter. Custom bots create O(platforms × agents) integration work; ACP reduces it to O(platforms + agents).
// Advanced
Can I use this framework with agents that aren't coding agents?
Yes. The architecture — ACP standardisation, concierge dispatch, disposable pods, SOP workflows, parallel channels — is agent-type agnostic. Replace coding harnesses with any ACP-compliant agent harness suited to your domain. The pattern works for content review agents, customer support agents, data analysis agents, or any task that is repetitive, high-volume, and requires judgment. The key constraint is that the agent must be wrappable as a harness.
What is the Ship of Theseus principle in harness evolution?
It means your agent harness doesn't need to be rebuilt from scratch as requirements evolve — it can be ripped apart and reassembled iteratively. The system's identity is maintained through continuity of use, not continuity of implementation. You can swap out the underlying model, change tooling, modify context management, and evolve the integration layer piece by piece while the harness keeps serving the same role in your orchestration system.
How do I scale from 5 agents to 500 agents on Kubernetes?
Use the Goal Operator to automate pod provisioning, lifecycle, and teardown — never manage pods manually. Configure cluster autoscaling so nodes scale with agent demand. Use helm charts for repeatable deployment. Implement resource quotas and priority classes to prevent runaway costs. The concierge pattern handles dispatch; the operator handles infrastructure. Monitor via structured JSON outputs from your SOP workflows to catch bottlenecks early.
Should I discard low-quality AI-generated PRs?
No. Even slop PRs are crucial user feedback data points indicating where something in the codebase is broken or confusing. Have your agent SOP categorise and bin them rather than discarding them outright. A PR attempting to fix something — even badly — tells you that something needed fixing. Aggregate these signals to identify hot spots in your codebase that need human attention or better documentation.
How do I know when to escalate from an agent loop to a human?
Distinguish between shallow bug loops and fundamental refactors. If the agent is uncovering and fixing superficial bugs — typos, missing null checks, simple logic errors — the loop is safe. If the fix requires changing architecture, redesigning an API, or making a judgment call about system design, break the loop and escalate. Encode this distinction explicitly in your SOP as a structured decision node with clear escalation criteria.