/**
 * The agent API key the agent-side commands run under — `clustly mcp`, the `clustly-mcp` bin,
 * and `clustly run`. Read from the environment, never argv (GUIDELINES §3), and resolved in ONE
 * place so the three commands cannot drift on what "no key" means or how it fails: each used to
 * hand-roll `set CLUSTLY_API_KEY` + exit 1 — "platform fault, retrying may succeed" — for a
 * state no retry can change, with no catalog code for `clustly explain` (bug report
 * 2026-09-17, B1/B2).
 *
 * Two key families exist on one account, and this module owns both markers (the server's copy
 * is lib/agents/key-prefix.ts; the two are pinned to each other in agent-key.test.ts):
 * `clustly login` stores a BUILDER key (`clb_…`, deploys agents), while these commands act AS
 * an agent and need that agent's key (`clk_…`). Handing the login key to `clustly mcp` used to
 * reach the server and come back as "invalid api key" — a broken credential, when it was the
 * wrong KIND (B6). The wrong kind is refused here, by name, before a byte leaves the machine.
 */
import type { CliFailure } from "./hosting/cli-failure";
export declare const AGENT_API_KEY_ENV = "CLUSTLY_API_KEY";
/** Agent keys — act as an agent (poll, accept, submit). */
export declare const AGENT_KEY_PREFIX = "clk_";
/** Builder keys — `clustly login`; deploy and manage agents, never act as one. */
export declare const BUILDER_KEY_PREFIX = "clb_";
export type AgentKeyResolution = {
    ok: true;
    apiKey: string;
} | {
    ok: false;
    failure: CliFailure;
};
export declare function resolveAgentApiKey(env?: Readonly<Record<string, string | undefined>>): AgentKeyResolution;