Crate scv_core 

SCV’s provider-independent agent loop and the traits it is built from.

AgentRuntime::run_turn runs one user turn: it selects the history the model sees, asks the Provider for a response, runs the requested Tools in order through the ApprovalGate, and repeats until the model answers without tool calls, reporting everything to an EventSink. ContextPolicy decides what history fits. This crate knows no concrete provider, tool, transport, or user interface; those live in the crates that depend on it.

Structs

AgentConfig

Settings of an AgentRuntime.

AgentRuntime

Runs user turns against one provider, tool registry, and context policy.

ApprovalRequest

AssistantResponse

The model’s complete answer to one request.

BudgetContextPolicy

Keeps the newest whole turns that fit ContextConfig’s budget and replaces older history with one bounded summary note.

ContextConfig

The token budget of BudgetContextPolicy. Tokens are estimated from serialized bytes, not counted by a tokenizer.

ContextError

Why no selection fits: the budget is too small even for the newest turn, or for the system prompt and tool schemas alone.

ContextSelection

The messages chosen for one model request, and what compaction cost.

HistoryLimits

ImageInput

An image file shown to the model with a user message.

ProgressSink

Where a running tool reports short status lines, such as a delegated agent’s commands. Each report becomes one bounded line; the runtime forwards the pending lines to the client at most twice a second and never adds them to the model’s history. The default sink discards reports, so a tool may always report.

ProviderError

ProviderRequest

One model request: the system prompt, the selected history, and the tools.

ToolApprovals

The session’s approval gate as seen by one running tool call. A tool that drives a nested agent (such as another SCV) asks it on the nested agent’s behalf, so the session’s policy and its user decide every nested side effect too. Without a gate, every request is denied.

ToolCall

ToolContext

What a running tool call gets besides its arguments.

ToolError

A tool call that could not run, such as invalid arguments. The runtime turns it into a failed ToolOutput whose content is message.

ToolOutput

A tool’s result as the model sees it. A failure is still a result: the model reads it and can react.

ToolRegistry

The tools of one session, by unique name.

ToolSpec

What the model is told about a tool: its name, what it does, and the JSON Schema of its arguments.

TurnInput

The user’s side of a turn: text, and images for a model that accepts them.

TurnOutcome

How a completed turn went: model requests made, and tokens used.

Usage

Token counts a provider reported; None when it reported none.

Enums

AgentError

Why a turn failed. The server maps each variant to a stable wire code.

CoreEvent

Message

ProviderErrorKind

What kind of failure a ProviderError is; the runtime maps each to an AgentError.

ToolFailure

Why a tool call failed. The model reads the call’s output either way; this tells the session’s clients what happened without reading the text.

ToolRisk

How much a tool call can affect; the approval policy decides per risk.

Constants

MAX_PROGRESS_EVENT_BYTES

Largest progress event: the newest lines reported since the previous event, with older ones dropped first.

MAX_PROGRESS_LINE_BYTES

Longest progress line a tool can report; longer lines are cut.

Traits

ApprovalGate

ContextPolicy

Decides which history messages go into each model request.

EventSink

Provider

A model backend. complete sends one request, streams text deltas to deltas, and returns the full answer with any tool calls. It must stop promptly when cancellation fires.

TextDeltaSink

Where a provider streams answer text as it arrives. An error from push means stop: the turn was cancelled or hit a limit.

Tool

Something the model can call. The runtime asks for the call’s risk and approval_summary first, so both must validate the arguments without side effects; only an approved call reaches execute.