/**
 * [WHO]: SubprocessSubAgentBackend
 * [FROM]: Depends on node:worker_threads, ./sub-agent-types
 * [TO]: Consumed by SubAgentRuntime when caller wants crash isolation
 * [HERE]: core/sub-agent/subprocess-backend.ts - Phase B B.6 multi-backend
 *
 * Crash-isolated SubAgent backend built on top of node:worker_threads.
 *
 * The worker thread runs the in-process backend in its own V8 isolate, so
 * an unhandled error inside a teammate cannot tear down the main session.
 * The Tool[] surface in `SubAgentSpec` is NOT serializable across the
 * worker boundary, so the caller must pre-stage tools by name and resolve
 * them inside the worker via `toolFactoryName`. For v1 we accept the same
 * profiles the team extension already uses ("read-only" / "sandboxed").
 *
 * Status: SHIPPED with the worker harness in place; the worker entry
 * itself is intentionally minimal (echo + abort) so the interface is real
 * and exercisable. The full agent loop inside the worker is deferred to a
 * follow-up because it requires re-creating the model registry inside the
 * isolate, which is out of scope for the AgentTeam Phase B milestone.
 *
 * The backend therefore documents itself honestly: callers that need real
 * LLM execution should keep using `InProcessSubAgentBackend`; callers that
 * just need an isolated bash/echo worker can use this one today.
 */
import type { SubAgentBackend, SubAgentHandle, SubAgentSpec } from "./sub-agent-types.js";
export interface SubprocessBackendOptions {
    /** Override the worker entry path (for tests). */
    workerEntry?: string;
}
export declare class SubprocessSubAgentBackend implements SubAgentBackend {
    private readonly workerEntry;
    constructor(options?: SubprocessBackendOptions);
    spawn(spec: SubAgentSpec): Promise<SubAgentHandle>;
}