Designing a Service-Request Agent That Can Stop Safely

A fictional intake service, with limited authority

This Design study proposes an assistant for a fictional public-service maintenance desk. A staff member describes a damaged street asset. The assistant drafts a structured intake request and may submit it within a predefined, authorized scope. It cannot dispatch crews, approve expenditure, declare an emergency resolved, or close a case.

All users, assets, records, and operating rules here are assumptions. No municipality, client, implementation, or service improvement is claimed. The purpose is to specify what the workflow should do when submission becomes uncertain, before connecting it to an operational system.

Define the two systems of record

The intake service would own the maintenance request. A separate workflow ledger would own the assistant's intent, authorization revision, attempts, and evidence. These records answer different questions. An assistant log can show that a call was dispatched; only an authoritative service record or a documented rejection can resolve what the service actually did.

Assume the service supports an operation identifier scoped to the submitting organization and action. It must bind that identifier to the original payload and create or replay the receipt atomically with the request. Its retention window must cover the permitted retry interval. These are requirements to verify, not capabilities assumed of an existing product.

AWS's idempotency guidance explains why an explicit request identifier and parameter checks matter. The proposed interface adopts that distinction between another delivery of one intent and a different requested action. [2]

Freeze the proposed action before dispatch

The draft contains a fictional asset reference, category, description, and submitting unit. A policy layer checks those fields and the current staff identity. A permitted submission receives one operation identifier and an immutable payload revision before its first network call.

If the staff member changes the asset or description while the first submission is unresolved, the assistant must preserve the earlier record. The change cannot become a silent replay under the same identifier. Resolve the earlier submission, then handle any authorized correction through the service's explicit amendment process.

OWASP's current Excessive Agency guidance calls for granular tools, minimum permissions, and authorization enforced independently of model output. Accordingly, the proposed assistant receives a specific intake tool rather than unrestricted database or command access. [3]

Use an unresolved state after a lost response

The proposed workflow moves from draft to ready, then dispatched. A valid receipt leads to confirmed. A documented rejection leads to rejected only when the service contract establishes that no intake request was created. A timeout, malformed receipt, or interrupted connection leads to outcome unknown.

From outcome unknown, the workflow first performs an authorized status lookup using the original operation identifier. A matching authoritative receipt resolves the submission. An unavailable lookup leaves it unresolved. An empty search result is insufficient if the service permits delayed writes or its lookup is eventually consistent.

RFC 9110 limits automatic retry of non-idempotent requests unless the client has additional knowledge about replay semantics or non-application. This design therefore requires a verified replay contract before a repeated submission; network silence is not that knowledge. [1]

Make recovery finite and durable

For illustration, assume one initial submission, at most one protected replay, and at most two status lookups within a fictional five-minute recovery window. These numbers are design inputs, not measured service objectives. The service owner must replace them with justified values before testing.

Persist the budget and its deadline with the workflow. Restarting a worker must not reset either. Before a replay, check current permission, payload identity, remaining budget, and the service's duplicate-protection window. If any check fails, transition to needs review without sending another mutation.

Stopping means the assistant stops issuing actions. It does not cancel an already dispatched request. A later receipt must be attached to the existing workflow and surfaced to the reviewer, rather than triggering a new submission.

Specify the handoff

The review record would contain the operation identifier, frozen draft, submitting identity, relevant permission revision, attempt times, receipts, lookup responses, and the reason recovery stopped. A named duty role would own reconciliation. This study does not appoint an actual person or claim an agreed response time.

When the service is unavailable, the staff interface should preserve the draft and show whether dispatch occurred. Any manual fallback needs a documented procedure for checking the unresolved operation first. Otherwise, a manual submission can duplicate the very request the automated workflow was trying to reconcile.

Evaluate effects separately from messages

A proposed test harness would control the fake intake service and inject failures before and after commit. Its authoritative store would reveal actual request counts. The workflow trace would reveal identities, decisions, and attempts. Comparing them would test both operational effects and the accuracy of user-facing status.

Planned cases include a stored request with a lost reply, two simultaneous deliveries, a restart before receipt persistence, permission revocation, a changed payload, an expired replay window, an unavailable lookup, and a late receipt after escalation. No such integration test has been executed here.

A candidate release would need evidence that one accepted intent produces at most one intake request within the verified contract, changed actions require new authorization, budgets survive restart, and every unresolved submission remains visible. A plausible final answer is not evidence for those properties.

What has actually been prepared

The linked research preparation pack adds an offline request-accounting function, a fixed synthetic fixture, and executable software tests. It separates attempts from logical requests and retains unresolved siblings after a success response. It does not implement this assistant, a durable ledger, or service-side idempotency.

Connecting the design requires an implemented test service, verified authorization and replay contracts, durable-state and concurrency tests, actual traces, and accountable operational review. Until then, this remains a bounded design proposal. The companion essay on ambiguous tool outcomes explains the testing rationale.