# Vendor-independent agents in Sidecat **Research recommendation · 27 September 2026 · not an implemented contract** ## Recommendation Define the responsibility before selecting its performer. A reusable Sidecat agent definition should describe a job, its required knowledge, methods, boundaries and results. An organization can bind that definition to a durable named agent and assign it work while no process exists. When work becomes ready, orchestration selects an eligible implementation and execution launches it with task-scoped authority. The model and harness belong to that activation, not to the business identity. Keep the responsibility addressable independently of its current holder. For collective work, assign a Plan occurrence to the responsibility, such as `messaging-maintainer`, and resolve an eligible current holder when it is claimed. A deliberate assignment to a particular agent is also possible. Replacing an agent must not strand the work, erase previous attribution or cause a second execution of an uncertain effect. This does not require a new object and service for every noun. A reusable responsibility/agent definition can be a package resource. An organization binding can use its existing membership, scoped-assignment and reference mechanisms. Runs, queues, policies and messages retain their respective owners. A one-off subagent does not need a permanent registration; the durable named agent is useful when there is ongoing assignment, communication or accountability. ## What the research established The study used current primary documentation, schemas and source, plus three independent reviews. These are source findings, not claims of runtime qualification. | Source | Actual mechanism | Consequence for Sidecat | | --- | --- | --- | | OpenAI and Claude agent definitions | Configurations combine instructions, tools and runtime settings. OpenAI saved configurations and sessions have different lifetimes. Claude custom subagents can start in separate context and resume through provider-specific session handles. | A provider configuration is an execution adapter target. It is not the durable organizational assignee. Preserve Sidecat task state independently of provider transcripts. [OpenAI configuration](https://developers.openai.com/api/docs/guides/agents-api/configuration), [Claude subagents](https://code.claude.com/docs/en/sub-agents). | | Agent Skills | A standard directory contains instructions, metadata and optional scripts/references/assets. It supports progressive loading. Tool allow-list support is experimental and varies across implementations. | Use Skills for reusable methods and knowledge delivery. A skill is not an assignment, approval or enforced permission grant. [Specification](https://agentskills.io/specification). | | A2A | The card/service schema describes an agent endpoint, skills, contact authentication, supported interfaces and a task/message/artifact lifecycle after contact. It does not prescribe how Sidecat should assign organizational work while the performer is offline. | Use an A2A adapter for external agents where useful. Keep an external Task ID associated with, but distinct from, a Sidecat Work/Plan reference. Discovery is not authorization or proof of skill. [Pinned protocol](https://github.com/a2aproject/A2A/blob/72b3761bd84c59291da694dcd97cdfc2c010df39/specification/a2a.proto). | | OASF and AGNTCY Directory | OASF catalogs skills, domains, locators and extensible modules, including evaluations and Agent Spec data. Directory separates content-addressed records from named references and searchable metadata. Its inspected installer derives Skills/MCP configuration rather than a general offline worker launch. | Consider compatible catalog import/export and vocabulary reuse. Do not equate a catalog entry, signature or evaluation reference with organization authority or task suitability. [Record schema](https://github.com/agntcy/oasf/blob/3c5053e8649b1925e0479993998ca34324447d4a/schema/objects/record.json), [installer](https://github.com/agntcy/dir/blob/3d3fd745b236238f70886bd99de032c3667dd982/cli/internal/agentinstall/derive.go). | | Open Agent Spec | Its Agent references an LLM configuration, prompt and tools. Disaggregated configuration permits model/tool components to be supplied separately. Runtime adapters translate supported constructs; the inspected OpenAI adapter explicitly rejects unsupported model configurations. | Adapt the separation of portable description and supplied implementation. Evaluate an Agent Spec import/export adapter if a real integration needs it. Do not replace Sidecat's business records or executable Lisp/workflow semantics wholesale. [Disaggregated configuration](https://oracle.github.io/agent-spec/26.3.1/howtoguides/howto_disaggregated_config.html), [pinned Agent source](https://github.com/oracle/agent-spec/blob/1362da5e8e9eb253f595a811632e99281767a123/pyagentspec/src/pyagentspec/agent.py), [adapter](https://github.com/oracle/agent-spec/blob/1362da5e8e9eb253f595a811632e99281767a123/pyagentspec/src/pyagentspec/adapters/openaiagents/_openaiagentsconverter.py). | | BPMN resource roles | The normative schema separates a resource role from a referenced resource or resource-assignment expression; Performer specializes ResourceRole. | The business duty/performer separation is established workflow practice. We can apply it without adopting BPMN as Sidecat's workflow language. [OMG schema](https://www.omg.org/spec/BPMN/20100501/Semantic.xsd). | The important qualification is that portable syntax does not prove equivalent behavior. Harnesses load context differently, support different tools and apply permissions at different layers. An adapter must expose unsupported requirements before performing an effect; it must not silently omit them. ## The Sidecat model | Fact | Authoritative owner | Lifetime | | --- | --- | --- | | Responsibility / reusable agent definition | Organization/records, distributable through packages | Purpose, component/product scope, knowledge references, methods, required capabilities, acceptance and escalation; survives a change of holder. | | Named agent and its responsibility binding | Organization, referencing an auth principal and messaging address as needed | Stable assignee; active/suspended/retired availability and authorized, dated responsibility bindings. No fixed model. | | Assigned work | Work/Planning | One Plan occurrence and its selected definitions, assignment/claim, progress and result. No duplicate agent-private task list. | | Eligible implementation | Execution/resources | A versioned harness/model/environment/tool configuration, availability, declared features and separately recorded observations/qualifications. | | Activation | Orchestration and execution, referencing auth decisions | Exact assignment, definition/method/context revisions, effective implementation, credentials/grants, result and unknown effects. Reuses run/allocation concepts. | These are ownership distinctions, not five compulsory new record families. In the smallest useful version, a responsibility and its named agent binding may be presented together. Reusable definitions are factored out when reused. Existing Sidecat actors can represent agents; adding a new organization-member kind merely because an agent is not human is not justified by this study. An illustrative definition could contain: ```yaml name: component-maintainer purpose: Maintain one component against its accepted product contract. scope_input: component knowledge: - accepted product requirements relevant to this component - its public contract and the contracts of actual consumers methods: - component-design-and-review - implementation-and-focused-tests - candidate-handoff required_capabilities: - inspect and modify the component repository - reason about its language and concurrency model - invoke the declared build and test tools results: - change with behavior evidence and updated documentation escalation: - proposed change to an accepted shared contract - unowned requirement or suspected authority problem ``` This is an explanatory example, not a frozen wire schema. Requirements, methods and knowledge should be typed references to versioned Sidecat records or package resources, not duplicated text. The organization supplies the component, accountable owner, resource limits, applicable policies and permitted implementations. Current policy is checked when admitting work and at the relevant effect boundary; an old definition cannot retain revoked authority just by pinning an old document. ## Registration and activation Registration should be a normal application operation available through the common bus, CLI, MCP and Lisp. It validates the definition and organizational binding, records a stable address, and makes that assignee discoverable under its access scope. It need not contact a model. Publishing a reusable definition into a marketplace neither registers it for a company nor grants it credentials. ```text product requirements / policies / knowledge / reusable routines | responsibility definition | organization binding and durable assignment address | Plan occurrence becomes ready | orchestration claims work and requests activation | eligible implementation + resources + effective authority | executor launches a bounded session | results / review / continuation in Sidecat ``` The ready-work record is durable; a bus notification wakes the dispatcher but is not the only copy of the obligation. A missed notification is recoverable through bounded reconciliation. Claim/lease and concurrency limits prevent accidental duplicate pickup. A pending unknown effect remains attached to its original request identity and is reconciled before a replacement worker repeats it. A provider change creates a new execution binding or activation. It preserves the responsibility, assignment and prior observations. Cross-provider continuation means resuming from Sidecat's retained task/results and an explicit context packet; it does not promise migration of a provider's opaque conversation or hidden state. An agent may hold multiple responsibilities. Initially, each activation should select one responsibility and assignment scope. Holding several duties does not automatically union their permissions. Later composite roles can be supported through an explicit authorization decision when there is a real need. ## Model suitability without vendor identity Separate three decisions: 1. **Hard eligibility:** required tools/protocols/environment are supported; the necessary resources and permissions can actually be granted; limits fit. 2. **Observed suitability:** evidence for this class of task using this model/harness/tool configuration. Retain evaluation version, conditions and unknowns. A self-description or a general benchmark score is not enough. 3. **Selection preference:** availability, expected quality, latency and cost among eligible choices, under the selected policy and budget. There is no universal scalar called model strength. A role can require an assessed capability such as Go concurrency review; the registry can compare candidates on that assessment. Qualification can be stricter for release or authority decisions than for a first draft. Optional routing tools such as Jev may help rank eligible choices; they do not create permission or determine an effect's success. A new model needs a way to acquire evidence. Policy can permit a bounded trial under review with a restricted task/resource scope. Its observed result becomes qualification evidence. Unknown suitability must neither silently count as proven nor permanently exclude every new implementation. Required technical support and actual authority remain prerequisites even for a trial. An adapter records effective settings, not merely the requested ones. A model name reported by a child, a launcher-observed configuration and a provider receipt have different evidentiary strength. Sidecat already anticipated this distinction in its runtime-allocation design. Exact retention is selected by the applicable policy; ordinary use need not retain every prompt or provider response. ## Existing Sidecat: reuse the ideas, verify the code At integration source `5f451c0b`, `internal/sideloop/state.go` combines a runner's name, command, directory, prompt, environment and inbox in `Profile`. `maintain/worker_setup.go:117` constructs a concrete Codex command with a model. `docs/first-worker.md` explains that the worker uses the prepared Sidecat identity and its name identifies a runner. This supports a prepared worker, but does not establish the provider-independent responsibility model above. The accepted [runtime allocation design](https://gitlab.com/sidecat-dev/sidecat/-/blob/fe64557720bd4f84e553dd559b3500d4fae30a67/architecture/specifications/runtime-allocation-and-delegation-provenance.md) already separates requested capability from effective provider facts and rejects a universal strength scale. [Harness principals](https://gitlab.com/sidecat-dev/sidecat/-/blob/fe64557720bd4f84e553dd559b3500d4fae30a67/architecture/specifications/authenticated-harness-principals.md) separate actor, enrollment, harness and session. The target-oriented messaging specification separates a durable participant from per-message actor/session provenance. These are good conceptual inputs, not proof that every declared feature is implemented. A live catalog search for allocation returned no matching operation in this study. Adapt those distinctions. Avoid copying the entire central schema or creating a second identity system. Admission of a named agent should reference the existing principal mechanism; authorization remains its own owner's job. Inspect and test the actual credential-delegation path before claiming that launching a worker gives it independent scoped authority. ## First proof before relying on this design Use one component-review responsibility, one named organizational assignee and two real harness adapters. This should be part of the resumed plan, not an extra agent framework built while the product plan remains under review. 1. Register the responsibility/assignee with both providers unavailable. Assign a review and inspect the pending work without launching anything. 2. Start one eligible adapter and observe a single claim, a bounded context and the real output contract. Confirm effective tool and permission settings. 3. Ask for a write under a read-only grant. The actual resource/operation boundary must refuse it, regardless of the prompt's wording. 4. Interrupt the worker, change the available model/harness, and resume from shared task state. Preserve identity, assignment, previous findings and unresolved effects; do not invent transcript continuity. 5. Replace the responsibility holder while work is pending. The new holder finds it; the old instance cannot complete a claim it no longer owns. History records who actually performed each attempt. 6. Change the definition or implementation while an activation is running. Existing work keeps its selected revision unless explicitly amended; new work can select the successor. Current revoked authority still applies. 7. Repeat with a fresh reviewer whose context does not contain the author's preferred conclusion. Detect a known requirement violation and preserve that finding even if the lead disagrees. No live adapter trials, paid provider calls or production changes were performed for this research. The recommendation is grounded enough to specify and test; it is not a claim that those seven checks already pass.