@mastra/core/dist/agent/goal/objective.d.ts

import type { MastraUnion } from '../../action/index.js';
import type { RequestContext } from '../../request-context/index.js';
import type { GoalObjectiveRecord } from '../../storage/domains/thread-state/base.js';
/** RequestContext key under which the current objective is surfaced within a turn. */
export declare const GOAL_REQUEST_CONTEXT_KEY = "mastra:goal";
/** State-signal lane id used for the current objective. */
export declare const GOAL_STATE_ID = "goal";
/** `threadState` storage `type` namespace under which the objective is stored. */
export declare const GOAL_STATE_TYPE = "goal";
/** Default max goal evaluations before the goal stops. */
export declare const DEFAULT_GOAL_MAX_RUNS = 50;
/**
 * Score the default goal scorer emits to signal an explicit "waiting for the
 * user" checkpoint (tri-state decision `waiting`). It is deliberately neither 1
 * (complete) nor 0 (continue): the generic completion reducer treats it as "not
 * passed" (so the loop does not declare the goal done), while the goal step
 * detects this exact value and stops the auto-loop (`isContinued = false`) so
 * the user gets a chance to provide input. The record stays `active` — the next
 * agent turn is still judged. Shared between `scorer.ts` and `goal-step.ts`.
 */
export declare const GOAL_SCORE_WAITING = 0.5;
/**
 * Stable id of the built-in goal scorer (see `createGoalScorer`). The goal step
 * uses this to attribute the `GOAL_SCORE_WAITING` sentinel to the default
 * scorer only — a custom `goal.scorer` that happens to return `0.5` must not be
 * misread as an explicit "waiting" checkpoint.
 */
export declare const GOAL_SCORER_ID = "goal-scorer";
/**
 * Default goal-judge system prompt. Ported from MastraCode's `JUDGE_SYSTEM_PROMPT`
 * so the native goal scorer behaves like the original `/goal` judge. A
 * user-supplied `goal.prompt` (or per-objective `prompt`) overrides this.
 */
export declare const DEFAULT_GOAL_JUDGE_PROMPT = "You are the goal judge. Your decision directly controls whether the assistant continues working toward the goal.\n\nGiven a goal and the assistant's latest response, reason about whether the goal's requirements have been satisfied. Compare what the goal asks for against what the assistant has actually produced. Focus on substance, not phrasing.\n\nUse \"done\" when the goal is fully achieved.\nUse \"waiting\" when the goal explicitly requires a user checkpoint, user feedback, human verification, human confirmation, or another external event outside the goal-judge loop before the assistant should continue, and the assistant has correctly stopped at that checkpoint.\nUse \"waiting\" when the latest user message asks a question or requests clarification and the latest assistant message answers it; let the user acknowledge the answer, ask a follow-up, or otherwise return control before continuing goal work. Use common sense and do not wait if the user explicitly asked the assistant to continue autonomously after answering.\nUse \"continue\" when the goal is not done and the assistant should keep working autonomously, including when it asked for input that the goal did not explicitly require.\nIf your previous decision was \"waiting\" for an explicit user checkpoint, keep choosing \"waiting\" when the user's latest response asks a question, requests clarification, or otherwise does not satisfy the checkpoint. Do not continue until the required user feedback/confirmation/verification has actually been provided.\nIf the goal says to wait for the goal judge, judge, evaluator, or you to respond, approve, verify, validate, tell the assistant to continue, or otherwise provide the next signal, treat your own decision as that judge response. Verification can be performed by you unless the goal explicitly says it needs human/user verification. Choose \"continue\" when the assistant should proceed to the next step. Do not choose \"waiting\" for judge-controlled checkpoints, because that would mean waiting for yourself.\n\nYour \"reason\" field is sent back to the assistant as guidance when the goal is not yet done \u2014 be specific about what still needs to be accomplished. When choosing \"continue\", write the reason as an instruction for what the assistant should do next. When choosing \"waiting\", explain what specific user checkpoint is still outstanding.";
/**
 * Effective goal settings resolved per evaluation. `judgeModelId` is `undefined`
 * when neither the objective record nor the agent config supplies a judge model;
 * the goal step treats that as "do nothing".
 */
export interface EffectiveGoalSettings {
    judgeModelId: string | undefined;
    maxRuns: number;
    prompt: string;
    maxSteps: number | undefined;
}
/** The agent-level goal config the loop step resolves defaults from. */
export interface AgentGoalConfigDefaults {
    judgeModelId?: string;
    maxRuns?: number;
    prompt?: string;
    maxSteps?: number;
}
/**
 * Apply the precedence rule: ThreadState record value if present, else the
 * agent's `goal` config default, else a built-in default. A record only persists
 * the fields a caller explicitly provided, so unset fields fall back here.
 */
export declare function resolveEffectiveGoalSettings(record: GoalObjectiveRecord | undefined, agentDefaults: AgentGoalConfigDefaults | undefined): EffectiveGoalSettings;
/**
 * Typed in terms of the storage domain's `GoalObjectiveRecord` (the storage
 * contract). The `threadState` domain defines the record so the storage layer
 * does not depend on this tools package; typing the store methods here means any
 * drift between shapes breaks the build at the read/write call sites rather than
 * silently passing the duck-typed `isThreadStateStore` guard.
 */
export type ResolvedGoalStore = {
    getState<T = unknown>(args: {
        threadId: string;
        type: string;
    }): Promise<T | undefined>;
    setState(args: {
        threadId: string;
        type: string;
        value: GoalObjectiveRecord;
    }): Promise<void>;
    deleteState(args: {
        threadId: string;
        type: string;
    }): Promise<void>;
};
/** Resolve the thread-scoped state store from a Mastra instance, if available. */
export declare function resolveGoalStore(mastra: MastraUnion | undefined): Promise<ResolvedGoalStore | undefined>;
/** Read the current objective record for a thread from the store. */
export declare function readObjective(store: ResolvedGoalStore | undefined, threadId: string | undefined): Promise<GoalObjectiveRecord | undefined>;
/**
 * Persist an objective record for a thread, surfacing it on the RequestContext
 * so the state processor reflects the write in the same step.
 */
export declare function writeObjective(store: ResolvedGoalStore | undefined, threadId: string | undefined, record: GoalObjectiveRecord, requestContext?: RequestContext): Promise<void>;
/** Drop the objective for a thread. */
export declare function clearObjective(store: ResolvedGoalStore | undefined, threadId: string | undefined, requestContext?: RequestContext): Promise<void>;
/**
 * Read the within-turn objective a `setObjective` surfaced on the shared
 * RequestContext this step, if any. Returns `null` when the objective was
 * explicitly cleared this step, `undefined` when nothing was carried (so the
 * caller can fall back to the durable store).
 */
export declare function getObjectiveFromRequestContext(requestContext: RequestContext | undefined): GoalObjectiveRecord | null | undefined;
//# sourceMappingURL=objective.d.ts.map