Jack Chen
cc2a83395a
DeepSeek retired the V4-Flash model and named the current generation `deepseek-flash`, with no version in the name. `deepseek-v4-flash` is still accepted, but DeepSeek documents it as a temporary compatibility name and already serves those requests from V4.1-Flash. The repository handed that name to users in the places most likely to be copied: the `oma` CLI default for `provider: 'deepseek'`, the adapter JSDoc that ships in the type declarations, the provider table in docs, the scaffolder env template, and every DeepSeek example. A copied name that the vendor calls temporary has an expiry date the reader cannot see. The provider table and the adapter JSDoc also stated that `deepseek-v4-flash` resolves to DeepSeek-V4-Flash-0731. That model is retired, so the sentence described a routing that no longer happens. Two corrections of the same kind travel with it. The thinking-mode note claimed the V4 models run at `high` effort, but the adapter forwards whatever effort the caller passes and sets none itself, so the claim is dropped rather than restated. Three `examples/basics` headers offered `deepseek-chat`, which DeepSeek retired outright on 2026-07-24 and which no longer resolves at all. The release bot moves to the same name. Callers that pass an explicit model are unaffected, and the old name keeps working for as long as DeepSeek accepts it. Left unchanged on purpose: `bench/config.json`, whose values are frozen controls for an already-run benchmark; the AtlasCloud pages, whose IDs come from that vendor's own model library; and the changelog history.
examples/integrations/
OMA wired to external systems: MCP servers, observability backends, other frameworks, app shells. Runnable starting points, not product docs.
Three categories live here.
Reference integrations demonstrate wiring against widely used protocols or frameworks. The OMA team maintains these once merged, regardless of who contributed them. Current:
mcp-github.ts: MCP servers viaconnectMCPTools().mcp-open-design.ts: batch fan-out over an MCP server's async, long-running jobs — N Open Design landing-page variants generated in parallel viarunTasks(), each variant drivencreate_project → start_run → poll get_runto a terminal status by deterministic code.external-agent-acp.ts: external coding agents (Gemini CLI / Claude Code) as team members via theacpbackend. See docs/external-agents.md.external-agent-process.ts: deterministic local subprocesses as team members via theprocessbackend.trace-observability.ts: theonTraceAPI.observability-v2/: no-network examples for batching/custom exporters, InMemory/File TraceStore, an application-owned OTel provider, and explicit CLI/server/serverless lifecycle handling. The originaltrace-observability.tsremains the legacy callback example.
Full applications embed OMA in a real app shell. Each has its own
package.json and start script (npm install then npm start or
npm run dev) instead of npx tsx, and imports the published
@open-multi-agent/core package name. The main index lists them under
apps. Current:
express-customer-support/: Express REST API +runTasks(). Contributed by @CodingBangboo via #191.with-vercel-ai-sdk/: Next.js + AI SDK +runTeam().
Vendor integrations show OMA paired with a specific third-party
commercial product and stay credited to the contributor. Naming follows the
shape of the example, not the vendor: a single-file script that wires one
protocol or MCP server keeps the protocol prefix (mcp-<server>.ts, as with
mcp-bilig-workpaper.ts and mcp-open-design.ts above), while a multi-file
integration that ships its own store, toolkit, or app shell lives under
with-<product>/. Current:
with-engram/: Engram memory backend. Contributed by @Agentscreator via #160.with-tencentdb-memory/: TencentDB-Agent-Memory long-term memory (L0→L3 pipeline) via its Hermes Gateway sidecar.
Submitting a reference integration
Open a PR following the conventions in examples/README.md.
For widely used protocols or frameworks, no prior discussion needed. For
niche ones, open a discussion first so we can confirm the wiring is worth
maintaining long-term.
Submitting a vendor integration
One condition: the integration is reciprocal. Your product's repo or docs should reference OMA as a supported integration. No payment involved, this is a signal filter for who has actually shipped against OMA.
Flow:
- Open a discussion with the link to OMA in your product's docs and a sketch of the example.
- Wait for a maintainer reply confirming the example is in scope.
- PR it. Follow the conventions in
examples/README.md.
If your product doesn't reference OMA yet, open a discussion to get listed in the Built with OMA section.
The Featured Partner program is separate and paid, for prominent README placement. Eligibility is an active OMA integration; reciprocal listing isn't required.
Out of scope here
- Marketing copy for a third-party product.
- Examples gated behind paid-only APIs with no free or trial tier.
- Thin
connectMCPTools()wrappers whose only difference frommcp-github.tsis the server name and prefix. Those belong in your own docs.