🌟SafeAgent x WisePick - Deterministic routing before exactly-once execution layers

[w2jmoe]

This is one of the few agent infra projects we’ve seen that treats execution semantics seriously instead of stopping at orchestration demos.

The “exactly-once execution guard” layer is extremely important once agents move into irreversible side effects.

We’re building WisePick:
https://github.com/w2jmoe/WisePick

A deterministic routing layer for agent runtimes.

One thing we’ve been noticing:
execution safety becomes much easier once the runtime can deterministically narrow execution paths before action dispatch.

Especially when:

• multiple tools overlap
• retries introduce ambiguity
• fallback chains become dynamic
• providers behave differently under failure

Your stack positioning:
Decision → Execution Guard → Receipt Layer

actually feels very clean architecturally.

We’ve recently been experimenting with runtime adapter patterns + observable routing contracts:
https://github.com/w2jmoe/WisePick/blob/main/docs/ADAPTER_PATTERN.md

Also aligned some telemetry concepts with Langfuse-MCP recently around routing observability.

Curious whether you see “deterministic pre-execution selection” eventually becoming part of production-safe agent stacks.

Great work. This is refreshingly infra-focused. 👀✨️

[azender1]

Thanks for the detailed framing — and yes, deterministic pre-execution selection is real and underspecified in most agent stacks right now.

The adapter pattern doc makes the boundary very clear: WisePick owns routing intent, the runtime owns execution. That's exactly the right separation. By the time SafeAgent's /claim is called, the routing decision has already been made — SafeAgent just enforces that the same decision can't fire twice.

One thing worth aligning on: your /v1/decide response includes a decision_id. The stack I'm working in (giskard09/argentum-core) already has a decision_id primitive from DashClaw — attribution + approval layer. Curious whether your decision_id is meant to be carried downstream into execution (as a correlation key), or whether it stays scoped to the routing layer. If it's a correlation key, WisePick slots cleanly above DashClaw and the full chain becomes:

WisePick (routing) → DashClaw (approval) → SafeAgent (exactly-once) → Mycelium (receipt)

Happy to look at whether the decision_id shapes are compatible.

[w2jmoe]

Thanks for the detailed framing — and yes, deterministic pre-execution selection is real and underspecified in most agent stacks right now.

WisePick (routing) → DashClaw (approval) → SafeAgent (exactly-once) → Mycelium (receipt)

Really appreciate this response 👋

And yes — the boundary separation is exactly what we’re trying to preserve:

WisePick owns routing intent / capability selection,
while the runtime stack owns execution authority, approval, retries, durability, and receipts.

The interesting part is your question around decision_id propagation 👀

Right now, WisePick’s decision_id is primarily routing-scoped:

• traceability for routing outcomes
• lightweight observability
• feedback association
• future routing evaluation

So today it is not yet a full runtime-wide execution correlation standard.

But we are increasingly thinking about whether decision_id should become a lightweight downstream correlation primitive across:

• routing
• approval
• execution
• receipt/telemetry

Especially as more runtime projects begin separating these layers independently.

The chain you described:

WisePick → DashClaw → SafeAgent → Mycelium

actually feels surprisingly clean architecturally 😊

And importantly:
we want to keep this lightweight and adapter-friendly,
not introduce another heavy coordination protocol.

So compatibility at the “correlation key / trace context” level is definitely interesting to explore.

[azender1]

That's a clean boundary — routing-scoped today, with room to evolve into a lightweight correlation primitive if the layers keep separating the way they are.

No need to force it now. If WisePick's decision_id eventually carries downstream as a trace context header, it slots naturally above DashClaw's approval primitive without either system changing its core design. The adapter pattern you described is exactly what makes that composable later without coupling it today.

Worth revisiting once you have a clearer picture of what downstream consumers actually need from the routing decision. Happy to compare field shapes when you get there.

[w2jmoe]

That's a clean boundary — routing-scoped today, with room to evolve into a lightweight correlation primitive if the layers keep separating the way they are.

Hey @azender1! Revisiting our thread because we just locked down a major upgrade regarding what downstream consumers get from WisePick.
To better serve approval layers (like DashClaw) and execution guards (like SafeAgent), our updated /v1/decide response now scores options using a dynamic ROI matrix. The decision_id now carries predictable metrics:

"metrics": {
  "predicted_latency_ms": 450,
  "cost_score": 0.12,
  "quality_baseline": 0.95
}

This means before SafeAgent enforces the exactly-once lock, your stack can now inspect the predicted cost and efficiency attached to that correlation key.
Would love to hear if this field shape slots cleanly into what you're seeing in the argentum-core workflow! 🤝✨

[azender1]

@w2jmoe — useful update. The metrics shape is clean. predicted_latency_ms and cost_score on the decision_id are the right fields for a downstream execution guard to inspect before committing a claim.
One question on the field contract: is decision_id stable across retries of the same routing decision, or does it regenerate on each /v1/decide call? For SafeAgent's exactly-once guarantee, the claim key needs to be stable — if the routing layer retries and generates a new decision_id, the guard can't correlate it back to the original committed claim.
If it's stable, the binding is straightforward: decision_id as the correlation key in SafeAgent's claim, metrics inspected before execution. Happy to compare field shapes once you have a spec or example payload.

[w2jmoe]

@w2jmoe — useful update. The metrics shape is clean. predicted_latency_ms and cost_score on the decision_id are the right fields for a downstream execution guard to inspect before committing a claim. One question on the field

Excellent catch. In our /v1/decide standard, each individual routing call generates a fresh decision_id. However, we explicitly carry a stable task_fingerprint in the metadata (generated deterministically from the user intent/payload).

For SafeAgent’s exactly-once guarantee, the task_fingerprint serves as the perfect stable correlation key across retries, while decision_id tracks that specific evaluation instance. We have already native-built this into the mcp.route_decision.v1 contract.

You can directly inspect the field layout (notice the task_fingerprint inside metadata) from our latest telemetry fixture here: 🤝✨️

[
  {
    "id": "obs_parent_turn_happy_01k9m4x7w2p3q8r5n6t1v0z3x",
    "traceId": "7c4e2a1f9b8d6035e7a2c4f1b9d8e7a6",
    "type": "SPAN",
    "name": "hermes.agent.turn",
    "startTime": "2026-05-15T08:42:17.100000Z",
    "endTime": "2026-05-15T08:42:17.500000Z",
    "parentObservationId": null,
    "level": "DEFAULT",
    "statusMessage": null,
    "version": "v0.1.6",
    "input": null,
    "output": null,
    "metadata": {
      "schema_version": "agent.turn.v1",
      "traceparent": "00-7c4e2a1f9b8d6035e7a2c4f1b9d8e7a6-1a2b3c4d5e6f7890-01",
      "session_id": "20260515_084217_a8c3f1",
      "turn_id": "turn_728ee14bc16146d19e8b4a11",
      "api_mode": "chat_completions",
      "wisepick_routing_enabled": true
    }
  },
  {
    "id": "obs_route_decision_happy_01k9m4x7w2p3q8r5n6t1v0z4y",
    "traceId": "7c4e2a1f9b8d6035e7a2c4f1b9d8e7a6",
    "type": "SPAN",
    "name": "mcp.route_decision",
    "startTime": "2026-05-15T08:42:17.128000Z",
    "endTime": "2026-05-15T08:42:17.129000Z",
    "parentObservationId": "obs_parent_turn_happy_01k9m4x7w2p3q8r5n6t1v0z3x",
    "level": "DEFAULT",
    "statusMessage": null,
    "version": "v0.1.6",
    "input": null,
    "output": {
      "selected_tool": "query_controlplane_logs",
      "capability_id": "k8s_log_analysis",
      "callable": true
    },
    "metadata": {
      "schema_version": "mcp.route_decision.v1",
      "traceparent": "00-7c4e2a1f9b8d6035e7a2c4f1b9d8e7a6-51ae0f9fcb372a4b-01",
      "decision_id": "dec_980cd1625b8047c977f6de870a1874a6",
      "policy_version": "wisepick-routing-policy-2026.05",
      "router_name": "WisePick-Decision-Engine",
      "router_version": "v0.1.6",
      "capability_id": "k8s_log_analysis",
      "provider": "ack_controlplane",
      "execution_type": "mcp",
      "callable": true,
      "confidence": 0.98,
      "latency_ms": 0.64,
      "candidate_count": 2,
      "top_candidates": [
        {
          "rank": 1,
          "tool_key": "query_controlplane_logs",
          "capability_id": "k8s_log_analysis",
          "provider": "ack_controlplane",
          "score": 0.98,
          "selected": true,
          "pruned": false,
          "reason_codes": [
            "capability_match",
            "direct_log_query"
          ]
        },
        {
          "rank": 2,
          "tool_key": "list_clusters",
          "capability_id": "k8s_discovery",
          "provider": "ack_api",
          "score": 0.41,
          "selected": false,
          "pruned": true,
          "reason_codes": [
            "redundant_path",
            "skipped_by_ecu_routing"
          ]
        }
      ],
      "reason_codes": [
        "capability_match",
        "historical_success_rate"
      ],
      "selected_tool": "query_controlplane_logs",
      "feedback_expected": true,
      "runtime": "hermes",
      "runtime_integration": "wisepick_tool_router",
      "pruned_redundant_paths": [
        "list_clusters",
        "get_all_pods"
      ],
      "decision_method": "ECU_Deterministic_Routing",
      "task_fingerprint": "76ec461e5d690268b1f414f26568974a9b30180e754691bd3360ea991de602d9",
      "session_id": "20260515_084217_a8c3f1",
      "turn_id": "turn_728ee14bc16146d19e8b4a11"
    }
  }
]

[azender1]

@w2jmoe task_fingerprint is the right answer to my question. A deterministically derived stable key that survives retries is exactly what SafeAgent needs as the claim anchor — decision_id per evaluation instance, task_fingerprint as the correlation key across retries. That separation is clean.

The binding is straightforward from here:

task_fingerprint → SafeAgent claim key
decision_id → metadata on the claim (which routing evaluation produced this)

On the metrics shape: predicted_latency_ms and cost_score on the decision give the execution guard useful signal before committing the claim. Not something SafeAgent acts on today, but the field is there when the stack needs pre-execution cost inspection.
Happy to compare against the argentum-core action_ref derivation when you have a spec written up. The task_fingerprint in your fixture is a SHA-256 hex — if the input preimage is documented, worth checking whether it aligns with SHA-256(agent_id || action_type || scope || timestamp_ms) or needs an adapter layer.

[w2jmoe]

@w2jmoe task_fingerprint is the right answer to my question. A deterministically derived stable key that survives retries is exactly what SafeAgent needs as the claim anchor — decision_id per evaluation instance, task_fingerprint as the correlation key across retries. That separation is clean.

The binding is straightforward from here:

Glad to hear this fits! task_fingerprint was indeed designed for stable correlation across retries. 🤗✨️

Regarding the preimage, our current logic is SHA-256(agent_id || task_intent || scope).

If this doesn't align with argentum-core's action_ref, we can either implement an adapter layer or standardize the logic in our v1 spec. Let me know what works best for your stack. 🤝

[azender1]

@w2jmoe — the preimage delta is small but worth pinning before it causes drift. Your SHA-256(agent_id || task_intent || scope) vs argentum-core's SHA-256(agent_id || action_type || scope || timestamp_ms) — two differences: task_intent vs action_type (probably compatible with a field rename) and the missing timestamp_ms.
The timestamp_ms is the one worth discussing. argentum-core includes it to make the fingerprint unique across separate invocations of the same action — without it, two different calls with the same agent, intent, and scope produce the same fingerprint, which would cause SafeAgent to SKIP the second one even if it's a legitimate new execution rather than a retry.
If WisePick's task_fingerprint is meant to be stable across retries of the same logical task but distinct across new tasks, you may already handle this implicitly through session or turn scoping. Worth checking whether your fixture's fingerprint would change between two separate user requests for the same action.
Happy to compare against a couple of concrete examples if you have them. If the scoping holds up, the adapter layer is probably just a field rename — no structural change needed.

[w2jmoe]

@w2jmoe — the preimage delta is small but worth pinning before it causes drift. Your SHA-256(agent_id || task_intent || scope) vs argentum-core's SHA-256(agent_id || action_type || scope || timestamp_ms) — two differences: task_intent vs action_type (probably compatible with a field rename) and the missing timestamp_ms. The timestamp_ms

Phenomenal catch! This highlights the exact architectural difference between routing and execution layers. 🤗✨️

To clarify our current setup: the timestamp-less task_fingerprint you saw is strictly isolated to our benchmark instrumentation (where we explicitly want time-agnostic hashes to group identical tasks across runs). In the production API (/v1/decide), we don't deduplicate by fingerprint at all; we generate a fresh UUID (decision_id) for every single invocation.

However, your point is 100% accurate for the integration boundary. When WisePick acts as the upstream for SafeAgent, the execution anchor absolutely requires temporal uniqueness. To perfectly align with argentum-core, adopting your SHA-256(agent_id || action_type || scope || timestamp_ms) logic at the adapter layer is the optimal path.

It sounds like this just requires a simple field mapping in the adapter (mapping our intent to your action_type and injecting the timestamp). If you have a concrete fixture/example handy, we can ship an integration patch aligning with this standard this week! 🤝

[azender1]

@w2jmoe — that clarifies it cleanly. Fresh UUID per call at the routing layer is the right design — dedup belongs at the execution layer anyway, which is SafeAgent's job.
For the adapter, the mapping is simple. Here's a concrete fixture:

import hashlib, struct, json

def wisepick_to_safeagent_request_id(decision: dict) -> str:
agent_id = decision["metadata"]["session_id"]
action_type = decision["output"]["selected_tool"]
scope = decision["metadata"]["capability_id"]
timestamp_ms = int(decision["startTime_ms"])

preimage = (
    agent_id.encode("utf-8") +
    action_type.encode("utf-8") +
    scope.encode("utf-8") +
    struct.pack(">Q", timestamp_ms)
)
return hashlib.sha256(preimage).hexdigest()

That derives a stable request_id from your mcp.route_decision.v1 payload fields. Same inputs always produce the same key — so a retry of the same routing decision maps to the same SafeAgent claim and gets SKIP. Happy to review the integration patch when you have it.

[w2jmoe]

@w2jmoe — that clarifies it cleanly. Fresh UUID per call at the routing layer is the right design — dedup belongs at the execution layer anyway, which is SafeAgent's job. For the adapter, the mapping is simple. Here's a concrete fixture:

Thanks for the deterministic ID fixture! I’ve implemented the SafeAgentAdapter based on your logic and merged it into our production branch (see implementation here).

Key Integration Points:

• Deterministic Idempotency: Implemented the hashlib logic as suggested to ensure that routing retries map to the same execution slot.

• Contract Alignment: The ecu_to_dispatch_request method handles the mapping from WisePick's decision payload to the SafeAgent invocation contract seamlessly.

• Verification: Added deterministic unit tests in tests/test_safeagent_adapter.py to ensure consistency.

Feel free to review! This has been a great engineering exercise for me, and I’m open to any refinements you might suggest. 🍎✨

[azender1]

@w2jmoe — reviewed the adapter. Implementation looks solid — the ecu_to_dispatch_request mapping is correct and the deterministic test coverage is exactly what this needs. One note: confirm startTime_ms is derived from the span's startTime field (converted to epoch ms) rather than a local clock at invocation time — that's the thing that makes the key stable across retries on different machines.
Happy to add adapters/safeagent_adapter.py as a named example in the SafeAgent repo too, so it's discoverable from both sides. Let me know if you want that cross-referenced.

[w2jmoe]

@w2jmoe — reviewed the adapter. Implementation looks solid — the ecu_to_dispatch_request mapping is correct and the deterministic test coverage is exactly what this needs. One note: confirm startTime_ms is derived from

Great catch! You're absolutely right—using local clock violates idempotency in distributed retries. I've refactored the logic to derive startTime_ms directly from the orchestrator's anchor, removing all dependencies on local perf_counter.

I've pushed the updates to adapters/safeagent_adapter.py and verified them with tests/test_safeagent_adapter.py. All 8 tests are passing. I'd be honored to have the adapter cross-referenced as a named example in your repo—let me know how you'd like to proceed! 🌸 (●°u°●)

[w2jmoe]

@w2jmoe — reviewed the adapter. Implementation looks solid — the ecu_to_dispatch_request mapping is correct and the deterministic test coverage is exactly what this needs. One note: confirm startTime_ms is derived from

Thanks again for the earlier feedback — we implemented the replay/idempotency example based on the adapter contract discussion and just merged it into the WisePick repo. 👏

Runnable replay demo:
https://github.com/w2jmoe/WisePick/blob/main/examples/safeagent_replay_demo.py

Integration notes:
https://github.com/w2jmoe/WisePick/blob/main/docs/integrations/safeagent.md

The demo verifies:

• fresh decision_id per routing evaluation
• stable deterministic request_id across retries
• RUN → SKIP replay semantics
• identical request_id reuse during replay
• execution stub invoked only once

We intentionally kept the boundary narrow:

WisePick → routing intent
SafeAgent → exactly-once execution semantics

Would be honored if the example could be cross-referenced from the SafeAgent repo as a replay/integration example as well 🤗✨️