The Multi-Agent Control Console: Subscription-Native Cross-Agent Orchestration Without API Keys; Secretary Suite Project
The Multi-Agent Control Console
Subscription-Native Cross-Agent Orchestration Without API Keys
Secretary Suite Project
Open-Source Concept Paper
John Swygert
August 24, 2026
Abstract
This paper proposes a local-first, open-source control program for coordinating multiple consumer artificial-intelligence services through the user's existing authenticated sessions. The proposed Secretary Suite Multi-Agent Control Console is not itself a conversational bot and is not intended to replace any participating model. It functions as a user-governed orchestration layer: the user selects which subscribed or freely available AI services should receive a task; the control program submits the task through provider-supported session controls; each service retains its own native conversation record; and the replies are returned to a common workspace for comparison, critique, synthesis, proofing, research, mathematics, coding, and other cross-agent work. The central design goal is to eliminate the unnecessary burden of API keys and duplicate usage billing when the user is already entitled to interact with the selected services through ordinary consumer accounts. The paper also specifies guardrails against uncontrolled autonomous agent loops, including explicit turn budgets, convergence detection, wall-clock limits, user-visible stop controls, provider rate limits, and account-level accountability. The proposal is intentionally open source, advertisement-free, local-first, and provider-respecting. Its broader claim is simple: cross-agent communication should become a normal consumer capability, not a developer-only privilege.
1. Secretary Suite Project Status
This paper is part of the Secretary Suite Project and should be read as an open architectural proposal rather than as a description of a currently standardized cross-provider product. It is intentionally provider-neutral. ChatGPT, Claude, Grok, Gemini, and other services are used here as examples of independently operated AI systems that a user may already access under separate consumer accounts. The paper does not assume that any provider currently permits every form of automation described below. Where provider cooperation or an official control surface is required, that requirement is stated explicitly as a design objective rather than treated as an existing entitlement.
2. The Problem
Consumers increasingly use more than one capable AI system. A researcher may ask one model to develop an argument, another to challenge it, a third to verify mathematics, and a fourth to inspect code. Today, however, the user often becomes the transport layer. Prompts are copied manually from one service to another; responses are pasted into new windows; context is lost; native thread histories diverge; and meaningful cross-checking becomes tedious. Developer frameworks already demonstrate the power of multiple conversational agents working together, but the ordinary consumer experience remains fragmented.
The conventional technical answer is to use provider APIs. That is appropriate for many developer products, but it solves a different problem. A consumer may already pay for multiple subscriptions or may be satisfied with the free usage tier of one service. Requiring that person to obtain API credentials, learn developer tooling, and pay metered API charges simply to coordinate services they can already use interactively creates unnecessary friction. The Secretary Suite proposal therefore asks a different question: can a user-controlled local program coordinate multiple already-authenticated consumer sessions without requiring the user to become an API developer?
3. The Control Program Is Not Another Bot
The proposed application should be understood as a control console, not as another general-purpose AI agent competing for the user's attention. Its primary job is orchestration. It routes instructions, preserves provenance, enforces limits, presents responses, and allows the user to define how participating models interact. The intelligence remains in the selected AI services; the control console provides the room in which they can work together.
This distinction matters for architecture and for trust. The console should not silently rewrite a provider's output, invent consensus, hide disagreement, or masquerade as a participating model. It should make clear which service produced which statement and should preserve the original responses whenever possible.
4. Core User Experience
5. Subscription-Native Session Control
The preferred architecture does not ask the user to paste API keys into Secretary Suite. Instead, the user signs into each provider through the provider's normal consumer authentication process. The provider remains responsible for credentials and account security. The Secretary Suite console receives only the minimum session-scoped permission necessary to open or continue a conversation, submit content, and retrieve the resulting response.
The ideal implementation is not brittle screen scraping. Providers should expose a small consumer-session control interface or operating-system intent layer designed for authenticated orchestration. Existing browser automation standards demonstrate that browser behavior can be controlled through standardized interfaces, but consumer cross-agent orchestration deserves a provider-supported abstraction with clearer permissions, provenance, and rate controls than generic automation alone.
6. Proposed Agent Relay Manifest
A minimal open interoperability standard could be called the Agent Relay Manifest. A participating provider would declare a small set of capabilities without exposing private model internals or requiring the user to manage developer credentials.
The critical principle is that the provider keeps control of the account and session. Secretary Suite coordinates; it does not extract reusable credentials. The user remains logged in, identifiable, rate-limited, and accountable under each provider's own account rules.
7. Native Threads and the Council Transcript
Every participating service should retain its own native conversation. This gives the user two records at once: the provider-side thread, which remains available inside the original service, and the Secretary Suite council transcript, which records the orchestration across services. The common transcript should include the user instruction, assigned role, provider identity, time, response, any subsequent cross-agent message, and the final human-selected or model-assisted synthesis.
This dual-record design improves provenance. If a later synthesis says that three models agreed on a mathematical step while one objected, the user should be able to open the underlying native threads and inspect exactly what each service said.
8. Cross-Agent Conversation Modes
9. Why Cross-Pollination Matters
Different models are trained, tuned, filtered, and instrumented differently. They can therefore fail differently. The purpose of a multi-agent console is not to create the illusion that majority vote equals truth. Its value is diversity of error surfaces. A mathematical argument that survives independent derivations is more interesting than one accepted by a single model. A paper that is challenged by separate systems can expose hidden assumptions. A codebase reviewed by models with different strengths can reveal defects that one system repeatedly overlooks.
The same architecture is useful when the systems disagree. Disagreement should be surfaced, not averaged away. The console can ask each model to state the premise on which its conclusion depends, request a targeted response to the competing claim, and return the unresolved issue to the human. Cross-talk is therefore a mechanism for structured epistemic friction, not merely a way to produce longer conversations.
10. The Autonomous-Loop Problem
If multiple conversational systems are allowed to answer one another indefinitely, they can consume enormous compute while producing diminishing informational value. An unconstrained round-robin loop is therefore unacceptable. The control layer must impose a finite autonomy budget before cross-talk begins.
11. A Practical Autonomy Budget
The following defaults are proposed for ordinary consumer use. They are intentionally conservative and should remain subordinate to stricter provider limits.
These numbers are design defaults, not universal laws. A short mathematical proof may need two rounds; a complicated code review may justify more. The important requirement is boundedness. Every autonomous exchange should begin with an explicit finite budget, and the human should be able to extend that budget deliberately rather than discovering that the models have been talking unattended for hours.
12. Convergence and Loop Detection
Round limits should be reinforced by semantic stopping rules. The console can compare successive responses and ask whether the conversation is still producing new claims, evidence, corrections, code changes, or unresolved questions. If two consecutive rounds are substantially repetitive, the system should pause and present a convergence notice. Likewise, if every active model independently reports that no material disagreement remains, the console can end the autonomous phase early.
The goal is not to automate a philosophical definition of truth. It is to prevent waste. A system that recognizes that the same three objections have been repeated twice is already safer and more useful than one that mechanically continues until a token limit is exhausted.
13. Human Authority
Secretary Suite should preserve a human governor above the council. The user can approve which services participate, assign roles, inspect the transcript, interrupt any exchange, remove an agent, extend a round budget, reject a synthesis, and decide what leaves the workspace. Autonomous cross-talk is a delegated subroutine, not sovereign authority.
This is particularly important for high-consequence work. Multiple models agreeing does not eliminate the need for domain expertise, source verification, testing, legal review, medical judgment, engineering validation, or human accountability. The console should make collaboration easier without laundering uncertainty into false certainty.
14. Account Accountability and Abuse Control
The proposed architecture is compatible with strong accountability precisely because users remain logged into their ordinary provider accounts. A provider can apply its normal usage limits, safety rules, suspension processes, and abuse controls. Secretary Suite should not offer anonymous relay infrastructure designed to hide the origin of automated traffic. Every request should remain attributable to the authenticated user who initiated the council.
Abuse prevention therefore becomes layered: Secretary Suite enforces finite conversation budgets and local controls; participating providers enforce account-level limits and acceptable-use policies; and the user remains responsible for the task being initiated. If an account is suspended by a provider, the console should display that state rather than attempt to bypass it.
15. No Advertising, No Pop-Up Economy
The reference open-source implementation should contain no advertising, no sponsored model placement, no pop-up marketing, and no sale of behavioral data. A control program that mediates intellectual work should not quietly rank agents according to affiliate revenue or interrupt research with promotional overlays. The user should decide which providers participate and in what order.
An open-source project still has costs. Those costs can be supported through voluntary donations, institutional sponsorship that does not alter ranking, paid support, hosted convenience services, or compatible commercial distributions. The core local orchestration logic should remain inspectable and usable without advertising.
16. Local-First Privacy Architecture
The common council transcript should be local by default. Provider responses necessarily pass through the relevant provider services, but Secretary Suite does not need a central cloud database containing every cross-agent conversation. Local storage reduces concentration risk and gives the user a clearer boundary around the combined transcript.
Synchronization across the user's own devices can be optional and encrypted. If a hosted sync service exists, it should be separable from the open-source local application. Users who do not want centralized storage should not be forced into it merely to coordinate agents.
17. Provider Cooperation Is the Better End State
A proof-of-concept could potentially use ordinary browser-control mechanisms where provider rules permit them, but the long-term design should not depend on fragile imitation of clicks or on evading anti-automation controls. The better outcome is for AI providers to recognize consumer orchestration as a legitimate use case and expose a narrowly scoped authenticated relay interface. That interface could preserve subscription rules, enforce rate limits, protect security, and still free consumers from manual copy-and-paste workflows.
This is not a demand that providers give away metered developer compute. It is a proposal for a different class of interaction: the same user, the same consumer account, the same normal usage entitlement, but coordinated through a local control program. Providers remain free to define reasonable orchestration limits for their own services.
18. Why Providers Should Want This
Cross-agent interoperability can look threatening because it reduces lock-in. It can also increase the value of every participating service. A model that is particularly strong at coding, mathematical criticism, long-context analysis, search, or prose editing can become more useful when it can occupy that role inside a broader council. Users may retain multiple subscriptions precisely because those services can cooperate rather than forcing the user to choose one exclusive ecosystem.
Interoperability also creates a healthier competitive signal. Providers can differentiate on reasoning quality, reliability, tools, privacy, context handling, speed, specialized capabilities, and price instead of relying primarily on friction that makes it difficult for users to compare outputs.
19. Research and Publication Workflows
For scholarly and technical work, the console can create reproducible council templates. A paper might be routed first to an independent summarizer, then to a methodological critic, then to a mathematics checker, then to a citation/source auditor, and finally to a synthesis agent. The transcript records which system made each objection and whether the author accepted, rejected, or revised it. This turns multi-model checking from an informal habit into a documented intellectual workflow.
The same approach can be used for software. One agent can implement, another can inspect architecture, another can generate tests, and another can analyze security or edge cases. Existing multi-agent research frameworks such as AutoGen and CAMEL demonstrate the general feasibility and usefulness of conversational agent collaboration; the Secretary Suite contribution is to argue for a consumer-facing, provider-neutral, subscription-native control layer rather than a developer-only API orchestration stack.
20. Mathematics and Proof Checking
Mathematics is an especially strong use case because independent derivation is valuable. The console can initially blind participating models to one another's solutions, compare results, identify points of divergence, and then begin a bounded critique round focused only on the disputed steps. Agreement is not proof, but disagreement is information. The workflow makes it cheap to ask, “Where exactly do these derivations cease to be equivalent?” rather than simply choosing the answer produced by the most persuasive prose.
21. Coding and Artifact Work
Cross-agent work becomes more powerful when the shared object is not only text. A future console should support governed artifact handoff: source files, test results, structured data, diagrams, drafts, and patches. Each agent should receive only the files and permissions required for its assigned role. Artifact provenance should record which service created or modified which version so that the human can compare alternatives and roll back changes.
22. Failure Modes
23. Open-Source Reference Implementation
The concept should be developed openly. A reference implementation can define the orchestration state machine, council transcript format, Agent Relay Manifest, role templates, autonomy-budget logic, convergence detection, local storage format, and provider-adapter interface. Provider-specific adapters can remain separate modules so that the core does not depend permanently on any one company.
An open implementation also makes the trust boundary inspectable. Users and providers can see what the console is sending, what it stores, when it stops, and whether it contains hidden telemetry or advertising logic. For a program designed to sit between multiple powerful AI systems, that transparency is not decorative; it is architectural.
24. Minimal Viable Product
A useful first version does not need full autonomous debate. It needs only four things: a local workspace, a way to select two or more already-authenticated providers, a provider-respecting dispatch/retrieval mechanism, and a combined transcript with source labels. The first automation mode can be parallel panel: one prompt, several independent answers, no cross-talk. A second release can add one bounded critic round. More autonomous council behaviors should be added only after stopping rules and provider controls are proven reliable.
25. Development Sequence
26. The Larger Principle
The user should not have to become an integration engineer merely to ask several AI systems to work on the same problem. Multi-agent reasoning is too useful to remain confined to API developers. As consumer AI becomes an ordinary intellectual tool, cross-model checking should become as natural as opening several references on the same desk.
The Secretary Suite Multi-Agent Control Console therefore proposes a simple shift in perspective: treat independently operated AI services as interoperable participants in a user-owned room. The user owns the objective, selects the participants, sets the limits, sees the provenance, and decides when the work is complete.
Conclusion
A future in which one person can sign into several trusted AI services and coordinate them through a single local control program is technically plausible, conceptually straightforward, and increasingly important. The difficult questions are not whether models can talk to one another; multi-agent research has already demonstrated that they can. The important questions are how that communication should be governed, authenticated, limited, recorded, and made useful to ordinary people.
The proposed answer is a subscription-native, local-first, open-source orchestration layer with no advertising, no pop-up economy, no requirement that ordinary users manage API keys, and no unbounded autonomous chatter. Each provider keeps its native account and thread. Each user remains accountable. Each agent is identified. Each autonomous conversation has a finite budget. The human remains in command.
If providers support this direction rather than resisting it, cross-agent collaboration can become a major new layer of consumer computing: one prompt can become a panel; one draft can receive several independent reviews; one mathematical claim can receive multiple derivations; one codebase can be attacked from several angles; and one researcher can coordinate intellectual diversity without manually carrying messages from window to window. The opportunity is not to build another bot. It is to build the room in which the bots can finally work together.
References
Wu, Q., Bansal, G., Zhang, J., Wu, Y., Li, B., Zhu, E., Jiang, L., Zhang, X., Zhang, S., Liu, J., Awadallah, A. H., White, R. W., Burger, D., & Wang, C. (2023/2024). AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv:2308.08155; later published at COLM 2024. https://arxiv.org/abs/2308.08155
Li, G., Hammoud, H. A. K., Itani, H., Khizbullin, D., & Ghanem, B. (2023). CAMEL: Communicative Agents for “Mind” Exploration of Large Language Model Society. arXiv:2303.17760. https://arxiv.org/abs/2303.17760
World Wide Web Consortium (W3C). WebDriver. W3C Recommendation, 5 June 2018; current specification series maintained by the Browser Testing and Tools Working Group. https://www.w3.org/TR/webdriver1/ and https://www.w3.org/TR/webdriver/
Comments
Post a Comment