Botmanor's control plane is, today, hand-driven. Somebody writes the system prompt, picks the model, guesses the retrieval settings, and later reads the execution list to work out what went wrong. That is a fair description of every agent platform on the market, and it is the part Botmanor intends to change — so this story is published as roadmap, with the design stated plainly rather than hinted at.
The copilot's first job is the activation cliff. Going from "we want a support bot" to a working bot means a provider, a model, a knowledge base, documents, an index, an agent, a prompt, an app, a link, a publish, a connector and a route. The design turns that into one sentence: describe the bot, and Botmanor drafts the graph — the app, one or more agents with generated prompts and capability flags, suggested routing links, suggested knowledge bases from what the workspace already has, and a suggested model from the providers already registered. Templates come first and generation second, because a proven template is a better starting point than a fresh guess. Crucially, nothing is committed live: every entity lands as a draft, and a human approves it entity by entity before anything goes active.
The copilot's second job is tuning, and it is grounded in evidence rather than advice. Reading an agent's own recent runs — cost, latency, how often retrieval returned nothing, which runs failed — it proposes concrete changes: raise or lower the retrieval count, move the similarity threshold, change the chunking strategy, tighten the prompt, downshift the model for cost. Every recommendation carries the run evidence that produced it.
The supervisor makes the same intelligence proactive. Agent fleets drift: knowledge goes stale, a prompt regresses after a publish, thresholds tuned for fifty documents stop working at five thousand, a model price change quietly triples a bill. The design is a scheduled review per workspace — built on the workflow engine already embedded in Botmanor rather than a bespoke cron — with detectors for failure-rate regression attributed to the publish that caused it, grounding decay, cost anomalies, latency drift, stalled indexes, idle agents that are retirement candidates, and stale knowledge. Findings arrive as decision cards in an operations feed: here is what changed, here is the evidence, here is the recommended fix, accept or dismiss.
Two commitments shape the whole design. Nothing auto-applies — accept and dismiss stay human, and the accept-or-dismiss signal is itself the feedback loop. And the detectors that need no judgement stay pure statistics, so a daily fleet review does not become a daily inference bill. Botmanor already has the substrate this runs on: the run ledger, the per-agent aggregations, the index status, the embedded workflow engine, and a decision store waiting for its first producer. What is missing is the producer — which is exactly what this work builds.
Because the copilot and supervisor surfaces do not yet exist in the web app, this page is presented as a narrative pattern rather than a clickable "Do it yourself" section.
Ready to make this your story?
