/**
 * Bedrock's adapter onto the shared agentic loop engine.
 *
 * Bedrock had two hand-rolled turn loops — one for `Converse`, one for
 * `ConverseStream` — that between them duplicated the same content-block
 * accumulation three times. Everything here is the wire-format half of that:
 * issuing the right command, folding a response into blocks, serializing tool
 * results back into the conversation, and mapping the stop reason. The turn
 * loop itself, the step cap, tool dispatch and usage accumulation belong to
 * `runAgenticLoop`.
 *
 * One adapter covers both operations because the two differ only in how a
 * step's content blocks arrive: `ConverseStream` delivers them as events that
 * are pushed to the consumer as they land, `Converse` returns them whole.
 * Block accumulation, tool-call extraction and the conversation shape are
 * identical, and were identical in the hand-rolled loops too — which is why
 * they drifted apart in the details.
 */
import type { ConverseCommandInput, ConverseStreamCommandInput } from "@aws-sdk/client-bedrock-runtime";
import { type BedrockRuntimeClient } from "@aws-sdk/client-bedrock-runtime";
import type { AgenticLoopAdapter, BedrockContentBlock, BedrockMessage } from "../../types/index.js";
export declare function createBedrockLoopAdapter(config: {
    client: BedrockRuntimeClient;
    /** `ConverseStream` when true, `Converse` when false. */
    streaming: boolean;
    /** The region the client was constructed with, for profile resolution. */
    region: string;
    maxSteps: number;
    /**
     * Build the request for one step. Synchronous by contract, so anything
     * async (tool declarations in particular) is resolved once before the turn
     * starts rather than per step. Bedrock has no mid-turn tool discovery, so
     * there is nothing that would need re-resolving.
     */
    buildCommandInput: (conversation: BedrockMessage[], step: number) => ConverseCommandInput & ConverseStreamCommandInput;
}): AgenticLoopAdapter<BedrockMessage[], BedrockContentBlock[]>;