Read-After-Write Consistency Prompt for Sequenced Operations

This prompt is designed for backend and agent infrastructure engineers who must guarantee that a read tool observes the result of a preceding write tool. The core job-to-be-done is enforcing strict ordering in a multi-tool sequence where a create, update, or delete operation must be fully committed and visible before a subsequent get, list, or search operation executes. The ideal user is an engineer building an agent execution engine, a stateful API integration, or a data pipeline where eventual consistency is not acceptable. Required context includes the specific tool definitions, the target system's consistency model, and the expected latency profile. Use this prompt when the model must reason about ordering dependencies explicitly and the cost of a stale read—such as a missing record, an incorrect state transition, or a duplicate write—is high enough to justify the added complexity of sequencing constraints and verification steps.

In practice, you should reach for this prompt when you are wiring together tool calls that share a mutable data store and the second call's correctness depends on the first call's side effects. For example, creating a user record and immediately fetching it to return a confirmation payload, updating a configuration and then reading it back to verify the change, or deleting a resource and then listing resources to confirm removal. The prompt produces a structured execution plan that includes sequencing constraints, staleness bounds, verification steps, and consistency level selection. It forces the model to treat the read-after-write dependency as a first-class constraint rather than an optimization hint. The output schema typically includes a sequence array with ordered steps, a consistency_level field (e.g., strong, bounded-staleness), a verification block with retry logic and timeout thresholds, and a fallback plan for when the read cannot be confirmed within acceptable bounds.

Do not use this prompt for independent parallel fetches where the read does not depend on the prior write's side effects. If you are fetching a user profile and a list of recent orders simultaneously from separate services, there is no write dependency to enforce, and adding sequencing constraints would only add latency and complexity without benefit. Similarly, avoid this prompt when the underlying system already provides strong consistency guarantees and the model does not need to reason about ordering—simply calling the tools in sequence with standard error handling is sufficient. If you are unsure whether a dependency exists, first use the Parallel vs Sequential Decision Prompt Template to classify the tool call group before applying this more specialized consistency prompt. The next section provides the exact prompt template you can adapt and embed in your agent harness.

This template instructs the model to act as a consistency planner for sequenced operations. It takes a set of tool calls—some of which write state and others that read it—and produces a strict execution plan that guarantees a read operation observes the result of a prior write. The prompt forces the model to reason about ordering, staleness, and verification before any tool is invoked, which is critical for backend engineers building multi-step workflows where eventual consistency is not acceptable.

codeCopy
You are a consistency planner for sequenced tool operations. Your job is to produce an execution plan that guarantees read-after-write consistency: any read tool that depends on a prior write tool's result must not execute until the write is confirmed durable and the read observes the updated state.

## INPUT
- Tool Calls: [TOOL_CALLS]
- Consistency Level: [CONSISTENCY_LEVEL]  # Options: strong, bounded-staleness, read-your-writes
- Max Staleness (ms): [MAX_STALENESS_MS]
- Timeout Per Operation (ms): [TIMEOUT_MS]
- Idempotency Keys: [IDEMPOTENCY_KEYS]

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "plan_id": "string",
  "consistency_level": "strong | bounded-staleness | read-your-writes",
  "execution_groups": [
    {
      "group_id": "string",
      "group_type": "sequential | parallel",
      "tool_calls": [
        {
          "tool_name": "string",
          "arguments": {},
          "operation_type": "read | write | read-after-write-verify",
          "depends_on_group": "string | null",
          "staleness_bound_ms": "number | null",
          "verification": {
            "required": true,
            "verification_tool": "string",
            "expected_field": "string",
            "expected_value_source": "string",
            "max_retries": 3,
            "retry_delay_ms": 100
          } | null
        }
      ],
      "barrier": {
        "type": "write-confirmation | staleness-wait | none",
        "condition": "string",
        "timeout_ms": "number"
      }
    }
  ],
  "failure_handling": {
    "on_write_failure": "retry_with_backoff | abort_chain | fallback",
    "on_verification_failure": "retry_read | abort | escalate",
    "on_timeout": "abort | partial_results | stale_read_allowed"
  },
  "audit": {
    "write_confirmation_id": "string",
    "read_timestamp": "string",
    "staleness_observed_ms": "number",
    "consistency_violation": false
  }
}

## CONSTRAINTS
1. Any read that depends on a prior write MUST be placed in a sequential group after the write's group.
2. For strong consistency, insert a verification read after every write before allowing dependent reads.
3. For bounded-staleness, calculate whether the expected replication lag exceeds [MAX_STALENESS_MS] and insert a wait barrier if needed.
4. For read-your-writes, ensure the same session or idempotency key is propagated to reads.
5. Parallel groups may only contain tool calls with no mutual dependencies and no write-write conflicts on the same resource.
6. Every write tool must include an idempotency key from [IDEMPOTENCY_KEYS].
7. If a verification read fails after max retries, mark the plan with a consistency_violation and follow the on_verification_failure policy.
8. Never schedule a read before its dependent write, even if the read appears faster.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]  # low, medium, high, critical

To adapt this template, replace each square-bracket placeholder with concrete values from your application context. [TOOL_CALLS] should be the full list of tool invocations with their arguments and declared operation types. [CONSISTENCY_LEVEL] must match your system's guarantees—use strong when the read must reflect the latest write, bounded-staleness when a small delay is acceptable, and read-your-writes when the same client session must see its own writes. [MAX_STALENESS_MS] and [TIMEOUT_MS] should come from your SLOs. [IDEMPOTENCY_KEYS] must be unique per write operation to prevent duplicate side effects during retries. [EXAMPLES] should include 2–3 few-shot demonstrations showing correct sequencing for your most common tool combinations. [RISK_LEVEL] drives the failure handling policy: critical should force abort-and-escalate on any verification failure, while low may permit stale reads with a logged warning.

Before deploying this prompt into production, validate the output against your tool registry to ensure every tool_name and verification_tool references a real, callable function. Add a post-generation validation step that checks for cycles in depends_on_group references and confirms that no read is scheduled before its declared dependency. For high-risk workflows, route the generated plan through a human approval gate before execution. Monitor the audit.staleness_observed_ms field in production traces to detect when real-world replication lag exceeds your configured bounds, and tune [MAX_STALENESS_MS] accordingly.

This prompt is not a standalone artifact; it is a guard stage inserted between a write tool call and any subsequent read tool call that depends on its result. In a sequenced execution engine, the harness must intercept the dependency graph, identify write-then-read pairs, and invoke this prompt with the write tool's completion status, the target read tool's schema, and the system's configured consistency level. The prompt returns a structured verdict: proceed, wait-and-retry, or abort-with-fallback. The harness must act on that verdict before allowing the read call to execute.

Wire the prompt into your orchestrator's pre-read gate. After a write tool returns a success acknowledgment, capture the write timestamp, the resource identifier, and the consistency model of the downstream datastore (e.g., DynamoDB eventually-consistent reads, Postgres replica lag, S3 strong read-after-write for new objects). Pass these into the prompt's [WRITE_CONTEXT] and [CONSISTENCY_MODEL] placeholders. The harness must also supply [STALENESS_BOUND_MS]—the maximum acceptable staleness in milliseconds—derived from the application's SLA. For high-risk operations (financial ledgers, inventory mutations, access control changes), set this bound to zero and require the prompt to recommend a synchronous verification read or a fencing token check.

The output schema must be parsed by a lightweight validator before the harness acts on it. Expect a JSON object with fields: decision (enum: proceed, wait, abort), wait_ms (integer, required if decision is wait), verification_read (object with tool name and arguments, optional), and rationale (string). If the validator rejects the output—missing fields, invalid enum, wait_ms exceeding a configured max—the harness must fall back to a safe default: either abort the read and escalate, or insert a conservative fixed delay (e.g., 500ms) and retry once. Log every verdict, the write timestamp, the actual read timestamp, and the delta for later staleness analysis.

Model choice matters here. This prompt requires strict instruction following and low-latency JSON output. Use a fast model (e.g., Claude 3.5 Haiku, GPT-4o-mini) for the consistency gate; the overhead of a large model can exceed the wait time it recommends. If the prompt is invoked on a hot path—every write-then-read pair in a high-throughput system—consider caching verdicts per consistency model and resource type, or precomputing static rules for known datastore behaviors. Reserve the LLM call for ambiguous cases: cross-system writes, multi-region replication, or user-defined consistency SLAs that change per operation.

Do not use this prompt as a substitute for datastore-level consistency guarantees. If your infrastructure provides strong consistency (e.g., read-after-write in a single-region S3 bucket for new objects, or a relational database with synchronous replication), skip the prompt entirely and rely on the datastore contract. This prompt earns its place when the system spans eventually-consistent stores, when replication lag is observable and variable, or when the cost of a stale read is high enough to justify the extra latency of a gate check. Pair it with a staleness metric in your observability dashboard: track the percentage of reads that returned data older than the write timestamp, and alert if the prompt's verdicts are not preventing real staleness incidents.