Adds an execution to one or more evaluation datasets as a sample
Snapshots the execution's inputs and outputs into each target dataset as an `EvaluationSample`, tagged with the supplied free-form tags. Use this to curate real-traffic examples into golden sets, regression suites, or labeled pools that feed evaluation runs. Re-adding the same execution to a dataset creates a new sample row rather than upserting, so callers that want at-most-once semantics should dedupe via `GET .../executionRecords/{executionRecord}/samples` first.
Authorization
Bearer JWT Authorization header using the Bearer scheme. Enter 'Bearer' [space] and then your token.
In: header
Path Parameters
The agent identifier.
The execution identifier.
The tenant identifier
Target dataset ids and optional tags.
Target dataset identifiers. One sample row is created per dataset.
Optional metadata tags to attach to each sample.
Response Body
curl -X POST "https://api.fruxon.com/v1/tenants/string/agents/string/executionRecords/string:addToDatasets" \ -H "Content-Type: application/json" \ -d '{}'[
{
"id": "00000000-0000-0000-0000-000000000000",
"tenantId": "00000000-0000-0000-0000-000000000000",
"createdAt": 0,
"modifiedAt": 0,
"createdBy": "string",
"datasetId": "00000000-0000-0000-0000-000000000000",
"executionId": "string",
"inputPayload": {},
"output": "string",
"agentRevision": 0,
"isGolden": false,
"tags": [
{
"id": "00000000-0000-0000-0000-000000000000",
"tenantId": "00000000-0000-0000-0000-000000000000",
"sampleId": "00000000-0000-0000-0000-000000000000",
"tag": "string",
"sample": null
}
]
}
]{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}{
"type": "string",
"title": "string",
"status": 0,
"detail": "string",
"instance": "string",
"property1": null,
"property2": null
}Lists execution records for an agent.
Returns a paginated list of all executions, ordered by most recent first. Optionally filter by time range using the `startTime` and `endTime` query parameters.
Terminally cancels a run, ending the execution.
The stronger counterpart to `:cancelWait`. Where cancelling the wait resolves the consult and <b>resumes</b> the run (so the agent can re-issue the same consult and re-park), this kills the run: every op the task is parked on is torn down, the task is flipped to a terminal state that never resumes, and the execution record is marked `Cancelled`. Use it when the run is stuck in a re-consult loop and skipping the single consult would not end it. Two kinds of run can be cancelled, and they answer differently. A run parked `WAITING_FOR_ASYNC` is killed synchronously here and returns `204` — nothing is executing, so there is nothing to interrupt. A run that is still `IN_PROGRESS` is executing inside a worker in another process, so the request is recorded on its queue row and returns `202`: the worker notices within a few seconds and aborts at its next cooperative checkpoint (immediately for an in-flight model call). Poll the record until its status becomes `CANCELLED` to observe the result — a run that finishes on its own first stays `COMPLETED`.