Adam Model Routing And Orchestration

Adam routes model work through Eve-managed model endpoints. That means teams can change providers, models, prompts, tools, approvals, and orchestration behavior without moving users or agents outside the governed Eve layer.

Model Control Plane

Adam can be configured with model endpoints and route aliases. A route alias is an Eve-facing name such as fast-summary, reasoning, or local-private-model; Eve resolves that alias to a concrete provider endpoint and applies the configured policy.

Common model controls include:

provider and endpoint selection;
model or deployment selection;
system prompt or assistant profile;
structured response format;
context and token budget expectations;
tool availability and tool-choice behavior;
parallel tool-call behavior;
cost, latency, and usage attribution;
PII, secret, and sensitive-input handling;
and per-request overrides where policy allows them.

Model providers are implementation choices behind the Eve endpoint. Adam can route to OpenAI-compatible endpoints, Anthropic, OpenRouter, Ollama, Azure OpenAI, or internal model endpoints when those endpoints are configured.

Orchestration Modes

Adam supports different execution modes depending on how much structure the work needs.

Mode	Use when	Behavior
Single turn	The request should produce one model response or one simple tool pass.	Adam sends the available governed context and returns the model response.
Tool loop	The model may need one or more governed tool calls before answering.	Adam presents tools, receives tool calls, asks Eve to authorize and execute them, then feeds results back to the model.
Plan then execute	Operators need to review tool calls before they run.	Adam returns a plan of proposed tool calls; a later request executes the approved plan.
Orchestrated	The task should be decomposed into subtasks.	Adam creates or receives a plan, scopes tools and model routes per subtask, runs eligible work in waves, and synthesizes the result.
Forced single	The caller wants to prevent multi-agent decomposition.	Adam keeps the request on the direct or tool-loop path even if orchestration is available.
Forced orchestrate	The caller wants explicit planning and subtask execution.	Adam uses the orchestration path and validates the resulting plan before execution.

Orchestration can use model route aliases per subtask. The planner may assign a route when a task clearly matches a configured model route, but it must use one of the available aliases; it should not invent provider or model names.

Governed Configuration Flow

What Operators Can Change

Operators can use Adam configuration to adjust:

which model endpoint a route uses;
which route an assistant or subtask should prefer;
whether a conversation is ephemeral or persisted;
which tools are available to a request;
whether reads can be auto-approved or every tool call requires approval;
whether a request should run as a single pass, tool loop, or orchestrated plan;
whether structured output is required;
which system prompt or assistant profile applies;
and how telemetry should be attributed for cost, latency, and audit.

These controls do not weaken endpoint access. A model route can change which provider answers, but it cannot grant access to an endpoint, tool, or data source that Eve denies.

Safety Rules

Treat model selection as policy, not application code.
Keep high-capability model routes separate from low-cost or low-latency routes.
Scope model routes to the skills and tools they are intended to use.
Use plan mode or explicit approval for high-impact tool calls.
Prefer forced-single mode for simple requests that should not spawn subtasks.
Prefer orchestration for multi-step operational work where decomposition, approvals, and artifact trails matter.
Monitor denied tool calls, provider failures, token usage, latency, and unexpected route selection.