Skip to content

Adapters and Backends

Sasha Lopashev edited this page Jun 27, 2026 · 1 revision

Adapters and Backends

Migaki should integrate with existing systems instead of replacing them.

Integration Modes

SDK Adapter

Applications or frameworks compile a workflow into mIR, call Migaki to optimize it, then execute the lowered plan.

This is the cleanest integration for systems that can expose logical execution structure.

Fetch-Compatible Wrapper

Migaki wraps provider calls at the HTTP boundary.

This is likely the easiest v0 integration. It can capture request context, estimate cost, detect stable prefixes, and emit evidence even when it cannot see the full application workflow.

Gateway Wrapper

Migaki sits above or beside a gateway such as LiteLLM, Cloudflare AI Gateway, or Vercel AI Gateway.

Migaki should not duplicate gateway responsibilities. It should provide execution plans and evidence while the gateway provides connectivity, limits, fallback, budgets, and monitoring.

Workflow Runtime Integration

Durable workflow engines own persistence and replay. Migaki can optimize model/tool execution inside workflow steps and emit evidence handles back to the workflow.

Trace Consumer

For closed or opinionated agent runtimes, Migaki may consume traces, infer execution patterns, and suggest optimizations without sitting in the direct execution path.

Backend Interface

interface ExecutionBackend {
  provider: string
  capabilities: ProviderCapabilities
  lower(plan: MIRPlan): Promise<ProviderExecutionPlan>
  execute(plan: ProviderExecutionPlan): Promise<ExecutionResult>
}

v0 Priority

Start with:

  • mock backend,
  • fetch-compatible wrapper,
  • OpenAI-style adapter,
  • Anthropic-style adapter,
  • optional LiteLLM-compatible backend.

Defer:

  • deep LangGraph adapter,
  • deep Vercel AI SDK adapter,
  • workflow engine plugins,
  • observability platform plugins.

The core plan, pass, backend, and evidence contracts should stabilize first.

Clone this wiki locally