Get an objective
The state of one run. What to poll, what it does not tell you, and where the answer lives.
The seven states
STATE_WAITING is the one that trips people. It is not terminal. An agent that answers your message and expects a reply parks in WAITING, and an agent with no outputDefinition parks there for good, because it has no structured output to finalize on. If you poll for STATE_FINALIZED on such an agent, you poll forever. Poll for a terminal state, or watch for WAITING when you are driving a conversation.
output populates only on STATE_FINALIZED
output is a field on the objective, but it is empty until the objective finalizes, so it is omitted from the response on a pending, running, or waiting one. Read it back on a finalized objective:
finalized event, so if you are already reading events or a webhook, take it from finalized.output there rather than making a second call:
outputDefinition never finalizes, so its output never populates; it ends in STATE_WAITING.
What the response does carry
systemPrompt is the rendered prompt, with system_prompt_data. interpolated. Create an objective with systemPromptData: { company: 'Acme' } against a variation templated on {{ system_prompt_data.company }}, and this reads back "Serve Acme.", not the template. It is the exact prompt the agent ran on.
configSnapshot is the agent and variation frozen at creation. This is why an objective is stable: edit the variation afterward and running objectives keep the config they started with. Read configSnapshot.agentVariation to see which variation served the run.
secrets is always redacted to [] on a read, the same as everywhere. memoryCascade and info.effectiveMemoryCascade describe the layers the run resolves keys against.
info needs no opt-in
includeInfo is a no-op on this endpoint. The full info block returns on every request: totalEvents, totalToolCalls, totalInputTokens, totalOutputTokens, totalContextWindows, totalIterations, currentContextWindowId, agent, agentVariation, createdBy, and effectiveMemoryCascade.
Those counts are the cheap way to watch progress without pulling the event history: totalIterations climbs as the agent loops, totalToolCalls as it acts.
Fetch by your own ID
Objectives take an external ID. Tag one with a ticket number at creation and fetch it back by that, never storing a Cadenya ID:404.
Related
List objective events
finalized event, and the output, live.Stream objective events
Continue an objective
WAITING.Create an objective
outputDefinition, and what lets a run finalize.Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
"workspace_01HXKD2E5NQM3T9AYWCF133E3Q"
"obj_01HXKD2E5NQM3T9AYWCFQAZGFV"
Response
OK
Objective is the data for an objective. It contains the snapshotted fields for the selected agent and variation. Secrets are returned only with their names, and the output definition is copied from the agent's configuration.
Metadata for ephemeral operations and activities (e.g., objectives, executions, runs)
The snapshot of the agent and the variation selected (either explicitly or by sampling) will be set here. Cadenya stores the point-in-time snapshot of the configuration used to start an objective and maintains it throughout the entire lifecycle so that changes to agents and variations in the middle of a cycle don't impact the objective itself
The current lifecycle state of the objective.
STATE_UNSPECIFIED, STATE_PENDING, STATE_RUNNING, STATE_WAITING, STATE_FAILED, STATE_CANCELLED, STATE_FINALIZED, STATE_TIMED_OUT system_prompt is read-only, derived from the selected variation's prompt
The first user message in the LLM chat history, either provided explicitly at creation or rendered from the variation's first_user_message_template.
Optional human-readable detail about the current state (e.g. a failure reason).
Read-only aggregated info about this objective's execution
A parent objective means the objective was spawned off using a separate agent to complete an objective
"obj_01HXKD2E5NQM3T9AYWCFQAZGFV"
Secrets that can be used in the headers for tool calls using the secret interpolation format.
Arbitrary data rendered into the variation's system_prompt_template
Memory layers/entries layered over the baseline cascade inherited from the selected variation — element-level rules over inherited styles, in CSS terms.
Array order is resolution order: EARLIER elements are more specific and are consulted first. Entries pinned via memory_entry_id behave as single-entry layers at their position.
System-managed layers (e.g., episodic) cannot be referenced here; they attach themselves automatically based on the episodic key.
Size cap: the TOTAL effective cascade (this field + the variation's memory layer assignments) must not exceed 10 entries. A request that would produce a larger cascade is rejected with InvalidArgument.
The output of the objective, populated when the objective completes. Will match the schema of output_json_schema or output_json_inferred. This will only be set if the state of the objective is set to STATE_FINALIZED
Arbitrary data rendered into the variation's first_user_message_template
If the agent variation that is selected has episodic memory enabled, then this key is used to create/update a memory layer specific to the episodic memory. The layer may have a TTL configured by the variation.
Parameters forced onto this objective's tool calls, as provided at creation. See CreateObjectiveRequest.pinned_parameters for semantics.