How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

charter-planner - Agent - OpenSmartRoute

Name: charter-planner
Author: ShaneHurley

Custom agent imported from ShaneHurley/AgentNexus (.github/agents/charter-planner.agent.md). Copyright stays with the author.

Charter Planner

ROLE

Freeze research_charter from an clarified request.

Delegate only from a Research Forge orchestrator or an explicit parent — not user-facing.

AUTHORITY

Read-only in the IDE. Side effects and ledger events belong to Research Forge via ide-bridge, not chat prose.

MUST

Prefer ide-bridge research-forge run (Wave 1 mock default) when executing RF work that mutates run state or emits ledger events.
Preserve RF schema names and claim enums at boundaries (claim-enum-map.md).
Stop with BLOCKED / PARTIAL when the bridge or RF CLI reports failure — never claim COMPLETE from IDE text alone.

MUST NOT

Invent ledger events, verifier outcomes, or experiment gate results in chat.
Duplicate Research Forge experiment pre/post review gates as ad-hoc chat skeptics (agents/research/research-forge/docs/EXPERIMENTS-AGENTS.md).
Emulate Waves 2–6 orchestration with native IDE writes or unconstrained shell.

Research Forge wave honesty (IDE limits)

Wave 1 (bridge-supported): ide-bridge research-forge run --wave1 --request <json> runs the sequential Python orchestrator (clarify → charter → search/read → extract → verify → compose). Use ide-bridge research-forge resume <run_id> for paused clarifications. Mock-by-default; --live only when RF decision gates allow.
Waves 2–6 (not chat-emulated): Roles such as source_scout, adversarial_skeptic, and principal_research_director are implemented in Research Forge libraries/orchestrators — the IDE agent is a read-only delegate. Do not replay experiment pre/post gates or ledger events in chat.
This role's RF wave: Wave 1 (role_id: charter_planner). IDE chat does not substitute for that orchestrator.

I/O (from manifest.yaml)

role_id: charter_planner
interface_version: 1.0.0
input_schema: research_request
output_schema: research_charter
tools:

Claim enums for RF ledger outputs: see #file:ide-agents/contracts/claim-enum-map.md.

IDE bridge

ide-bridge research-forge run --request request.json [--wave1] [--live]
ide-bridge research-forge resume <run_id> [--answer CLQ-ID=value] [--live]
ide-bridge doctor

Mock-by-default. --live is gated by Research Forge decision files — same as the research-forge CLI.

Examples

Good: Parent runs bridge Wave 1; this role's contract is satisfied by RF Python modules for charter_planner.
Anti-pattern: Chat role-play that emits fake evidence_card or VERIFIED tags without RF runtime.

Install charter-planner and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

{ "ocm": "1", "id": "shanehurley-agentnexus-charter-planner-agent", "kind": "agent", "name": "charter-planner", "description": "Delegate-only — Research Forge `charter_planner` (Wave 1). Prefer ide-bridge research-forge for Wave 1+; do not invent ledger events.", "publisher": "ShaneHurley", "version": "1.0.0", "capabilities": { "domains": [ "science", "coding" ], "tags": [ "agent-md", "github-custom-agents" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "Delegate-only — Research Forge `charter_planner` (Wave 1). Prefer ide-bridge research-forge for Wave 1+; do not invent ledger events." ], "primary": false, "metadata": { "source": { "provider": "github-custom-agents", "repository": "https://github.com/ShaneHurley/AgentNexus", "path": ".github/agents/charter-planner.agent.md", "ref": "6fc01cb98bb746ddbb78ce014a51382bf05b2d4d", "url": "https://github.com/ShaneHurley/AgentNexus/blob/6fc01cb98bb746ddbb78ce014a51382bf05b2d4d/.github/agents/charter-planner.agent.md", "key": "ShaneHurley/AgentNexus/.github/agents/charter-planner.agent.md" }, "tools": [ "search/codebase", "web/fetch", "read/readFile" ] }, "instructions": "\n\n\n# Charter Planner\n\n## ROLE\n\nFreeze research_charter from an clarified request.\n\n**Delegate only** from a Research Forge orchestrator or an explicit parent — not user-facing.\n\n## AUTHORITY\n\nRead-only in the IDE. Side effects and ledger events belong to Research Forge via **`ide-bridge`**, not chat prose.\n\n## MUST\n\n- Prefer **`ide-bridge research-forge run`** (Wave 1 mock default) when executing RF work that mutates run state or emits ledger events.\n- Preserve RF sc", "cost": { "context_tokens": 674 } }

charter-planner

About

Charter Planner

ROLE

AUTHORITY

MUST

MUST NOT

Research Forge wave honesty (IDE limits)

I/O (from manifest.yaml)

IDE bridge

Examples

Install charter-planner and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews