Affected Component
Use-case repos: statewave-personal-assistant, statewave-multi-agent-memory, statewave-multi-agent-shared-context
What I found
None of the three SDK-based use-case repos ever sends caller_type, and only one sends caller_id:
| Repo |
caller_id |
caller_type |
statewave-multi-agent-shared-context |
yes (core/statewave_client.py:60) |
no |
statewave-multi-agent-memory |
no (statewave_tools.py:98) |
no |
statewave-personal-assistant |
no (app/services/statewave.py:112) |
no |
A grep for caller_type across all four use-case repos returns nothing.
The SDK supports both:
>>> inspect.signature(statewave.StatewaveClient.get_context)
(self, subject_id, task, *, max_tokens=None, session_id=None, emit_receipt=None,
query_id=None, task_id=None, parent_receipt_id=None, caller_id=None, caller_type=None)
And the server treats their absence as significant. server/api/context.py:36-45:
if tenant_config.get("require_caller_identity") and (
not body.caller_id or not body.caller_type
):
raise HTTPException(status_code=401, detail=...)
So a reader who copies any of these integration patterns — and statewave_tools.py and statewave_integration.py are explicitly written to be copied — into a tenant with require_caller_identity: true gets a hard 401 on every retrieval, from code that works fine against a default tenant. On a tenant in policy_mode: enforce the failure is quieter: server/services/policy.py matches rules on caller_type, so an absent one is the least-privileged caller and the bundle is thinned with no error at all.
Suggested resolution
Have the demos model the call the way a real deployment should make it — pass a caller_id and a stable caller_type per agent role (planner, reviewer, chat, …), which is also a nicer illustration of what policy rules match on than omitting them.
The mechanical part is small (one argument at each of the three call sites). The part I'd rather not decide alone is whether every demo should carry policy-grade identity, or whether one of them should show it and the rest stay minimal — happy to send the PR either way once someone picks.
Environment
All repos at main as of 2026-09-07; server read at 1.5.0.
Affected Component
Use-case repos:
statewave-personal-assistant,statewave-multi-agent-memory,statewave-multi-agent-shared-contextWhat I found
None of the three SDK-based use-case repos ever sends
caller_type, and only one sendscaller_id:caller_idcaller_typestatewave-multi-agent-shared-contextcore/statewave_client.py:60)statewave-multi-agent-memorystatewave_tools.py:98)statewave-personal-assistantapp/services/statewave.py:112)A grep for
caller_typeacross all four use-case repos returns nothing.The SDK supports both:
And the server treats their absence as significant.
server/api/context.py:36-45:So a reader who copies any of these integration patterns — and
statewave_tools.pyandstatewave_integration.pyare explicitly written to be copied — into a tenant withrequire_caller_identity: truegets a hard 401 on every retrieval, from code that works fine against a default tenant. On a tenant inpolicy_mode: enforcethe failure is quieter:server/services/policy.pymatches rules oncaller_type, so an absent one is the least-privileged caller and the bundle is thinned with no error at all.Suggested resolution
Have the demos model the call the way a real deployment should make it — pass a
caller_idand a stablecaller_typeper agent role (planner,reviewer,chat, …), which is also a nicer illustration of what policy rules match on than omitting them.The mechanical part is small (one argument at each of the three call sites). The part I'd rather not decide alone is whether every demo should carry policy-grade identity, or whether one of them should show it and the rest stay minimal — happy to send the PR either way once someone picks.
Environment
All repos at
mainas of 2026-09-07; server read at 1.5.0.