[Use Case] Maintaining agent identity and action-time state across changing executions

1. Identification

Title: Maintaining agent identity and action-time state across changing executions
Submitting organization: Forkit AI
Contact name: Syed Amir Hamza
Contact email: sa.hamza@forkit.dev

Sector (tick all that apply; a cross-industry case may tick more than one):
- [ ] Education
- [ ] Displaced persons / humanitarian
- [ ] Health
- [ ] Financial services
- [ ] Telecom
- [ ] Media and publishing
- [ ] Logistics
- [ ] Energy
- [ ] Critical infrastructure
- [ ] Smart home / IoT
- [x] Other (specify): Customer-support operations; potentially reusable across sectors.

Status: Hypothetical, implementation-neutral discussion case. Scenario facts and expected outcomes are proposed, not implementation results or adopted requirements.

2. The situation

Plain language description (required, 3 sentences max):
A service organization wants to add reviewable identity and action-history evidence to an existing support workflow without replacing its agents, identity provider, ticketing system or authorization controls. Support Agent A routes a request, later runs with changed configuration in a new execution, and shares its model and runtime build with a separate Billing Agent B. A reviewer who was not present must establish which execution made each change, its supported association with an agent identity, and the relevant state at that moment, while keeping missing evidence and unsupported continuity claims visible.

Actor (every party involved):
The organization as principal, deployer and internal infrastructure operator; its authorized operations manager; distinct logical agents A and B and their executions; the existing harness, identity/authorization service and ticketing service; and a later internal reviewer. All systems are internally operated in the base case.

Action:
Read a synthetic request and update its assigned queue. Payments, external messages and physical actuation are excluded. The queue update is reversible; downstream effects would require separate treatment in a live pilot.

Decision required (at the moment the agent acts):
May the ticketing service accept this request under existing authorization rules, and is the required evidence available to bind its record to this execution and relevant state? Existing controls decide admission. The later reviewer separately assesses what the retained record establishes; this case does not define a permission engine.

Problem encountered:
In this hypothetical starting workflow, the ticket log names a shared service account, deployment records show current configuration, and harness logs identify runs separately. After an update, the reviewer cannot reliably connect an old action to its execution and state. This limitation is a scenario assumption, not a claim about every product or standard.

Current mitigation:
Staff manually correlate these records and identity/authorization references. Some actions remain insufficiently attributable.

Residual gap:
The selected records lack supported action-to-execution-to-state links, a reviewable continuity basis, and scoped uncertainty findings. These links can span existing systems; a single database or universal agent identifier is not required.

Functional flow and adoption boundary

1. Start with existing systems. Identify actor/run identifiers and sources; declare the action boundary, material-state scope, trust assumptions and retention period.
2. Start scoped recording at T0. Reuse sufficient existing records; add instrumentation only where needed. Importing logs does not validate missing links, and onboarding does not retroactively prove earlier history.
3. Record action X. E1, associated with A, requests X under S1. Link the receiver's admission and outcome; distinguish request, acceptance and completed effect.
4. Change execution/state. E2 starts under S2, possibly in another internal environment. A claim that E2 continues A retains its source and basis. Current authorization is checked separately; earlier approval is not automatically transferred.
5. Separate actors. B requests Y using the same model/runtime build as A. Supported bindings still distinguish agents and executions.
6. Review X and Y. Use the declared profile, not current state as a historical substitute. Missing, withheld or conflicting evidence limits the finding.

Adoption intent: Start with one workflow, preserve existing controls, and reuse relevant evidence with its source/scope/time. Evidence reuse does not automatically transfer permission to another context. No vendor, framework, cloud, ledger or new credential format is mandated. Feasibility and adoption benefits remain unmeasured.

3. Actors and context

Taxonomy roles involved
- [x] Principal — the service organization.
- [x] Relying party — the ticketing service at admission; a later reviewer for the historical account.
- [ ] Builder
- [x] Deployer / Owner — the service organization.
- [x] Agent instance — the distinct executions of A and B.
- [x] User — the authorized operations manager who configures and initiates the workflow.
- [x] Infra provider — the organization's internal infrastructure operator.
- [ ] Attestor — no separate remote-attestation service is assumed in the base case.
- [x] Other (specify): Evidence-producing harness and ticketing service; identity/authorization service; later reviewer.

Mandates in this case (required)

Proposed case facts: Domestic Germany; German law is the governing legal regime. Policy P1 separately defines operational scope. Authority validity/applicability are stipulated technical-case inputs, not legal findings about a real deployment or software legal personality.

Cross-border?
- [ ] Yes — jurisdictions involved:
- [x] No — the proposed base case is domestic Germany.

Embodied (physical actuation or sensing)?
- [ ] Yes — physical context:
- [x] No

Agent action type (required; tick all that apply; the most consequential governs the case)
- [x] Read-only — inspection of the synthetic request.
- [x] Consequential (reversible) — the queue update governs the case classification.
- [ ] Irreversible

Crosses organisational boundary? (required)
- [ ] Yes (specify):
- [x] No — different execution environments remain inside the same organization.

Risk level (required)
- [ ] Low
- [x] Medium — proposed classification for misrouting/delay and misleading operational records in this bounded service scenario, not a regulatory risk classification.
- [ ] High

4. Theme relevance

Related theme proposals:
- Primary contribution: Theme #1 — Accountability and attribution after an agent has acted.
- Authority interface: Theme #5.
- Optional suspension/resumption interface, not a second authority model: Theme #16.

5. Requirements

Candidate requirements, not adopted text or prescribed encoding. State/continuity assertions reuse Theme #1's carried-claim properties: source attribution, relevant timing, scope, supporting evidence and integrity/assurance limits.

Working distinctions: Logical agent: continuing identity under the deployment's declared rules, where present. Execution: a particular run/worker. Effective state: material operating conditions relevant to the action boundary, not every internal variable. Continuity associates executions with an identity; lineage concerns derivation and needs separate support.

Deployment constraints: Preserve access restrictions; do not require raw customer content, secrets, weights or private memory. Retrospective links retain their later derivation time; stronger later assessments do not erase earlier limited findings. No new retention or legal-compliance framework is proposed.

6. Assessment criteria

Declare before evaluation: Required scope: action/receiver outcome, execution, agent binding where applicable, runtime/build reference, model reference and routing-configuration version at the action boundary. Specify identity-binding rules, accepted sources, evidence cut-off, assurance and retention. A provider-reported model reference is not a verified weight fingerprint. These are case-specific information needs, not universal schema fields.

Success criteria:

The following are proposed written cases and expected findings, not completed tests.

Boundary checks within the same use case:
- Restart/migration: Compare an attributable, supported continuity claim with a restart using the same checkpoint but lacking that evidence. The latter leaves continuity unestablished; it does not prove that the executions are unrelated. Concurrent executions, if permitted by the declared identity rules, remain separately attributable.
- Adoption and absent identity: An action before T0 with no retained state binding cannot acquire a complete historical account merely through onboarding. A temporary worker assigned no separate logical-agent identity remains attributable to the supported execution/harness context, with the limits explicit, rather than receiving a retrospectively invented identity.

Measurable metric:

Targets for later validation; no measurements are reported in this submission.
- Correct actor/execution/state associations divided by the positive cases with the required supporting evidence. Report failures and abstentions separately; returning unknown for every case does not pass.
- False continuity or actor-merger findings divided by negative cases; target zero on the explicitly enumerated cases, not a claim of zero real-world error.
- Unsupported complete-state findings divided by incomplete-evidence cases; target zero on the enumerated cases.
- Assessments retaining their source, scope, time and cited evidence divided by all assessments.
- For any later adoption pilot, report systems replaced, new integrations required, added event latency, metadata/storage cost and investigation effort. No benefit or performance result is asserted in this hypothetical submission.

7. Duplication check

Existing standards or SDOs:

Initial, non-exhaustive mapping:

Overlap notes: This tests composition of existing mechanisms across lifecycle changes, not the invention of provenance or identity. The mapping is non-exhaustive: existing requirements should be referenced or consolidated where they cover a case. Specific SG17 overlap remains open for review under FG-TIDA's process.

8. Maturity

Pilot status
- [x] Hypothetical
- [ ] Pilot in progress
- [ ] Deployed in production

Reference implementation: n/a. No implementation or executed validation is presented in this submission. Later non-normative mappings must be assessed against the same cases.

9. IP and confidentiality

Confidentiality level
- [x] Public
- [ ] FG-internal only
- [ ] Redact before publication

IP notes:
No private implementation assets or prescribed proprietary mechanism. Future assets require separate disclosure/licensing review. No ITU endorsement, certification, legal-compliance finding or patent-clearance guarantee is asserted.

10. Assets

Link to assets:
- [ ] Dataset
- [ ] Code
- [ ] Protocol
- [x] Other: The proposed functional flow, case facts, candidate requirements and expected findings are included in this submission. No external executable asset is presented.

Discussion provenance:
This develops the identity/state-continuity contribution in Theme #1, including Anton's requested cases and scope, the contributor's scope confirmation and the ephemeral-execution discussion. It is a design contribution; the separate request for implementation-grounded evidence remains unanswered by this document.

IP notes: Any later validation artifact must state authorship, version, provenance, disclosure restrictions and its limited claim separately.