Did you know that a server can report HTTP 200 for a batch of actions even though some individual items failed? An AI agent asked to update four worksheets, delete several objects or publish a series of articles must not assume one overall response describes every item. Some APIs apply a batch atomically; others return a mixture of successes and failures. Trustworthy automation reads the actual provider contract, tracks a stable identity for each intended change and verifies every completed effect.
The practical method is to distinguish atomic transactions from per-item batches, validate each item’s scope and target revision, record an item-level ledger, interpret provider-specific responses and reconcile unknown effects before retrying. This guide works through an invented eighty-item batch, contrasts Google Sheets atomic batchUpdate with Amazon S3 multi-object delete and transfers the method to a school worksheet workflow. All amounts and results are fictional examples, not real eduKate publishing figures or proof that artificial superintelligence exists.
This specialist article belongs to How Super Intelligence Works. The Agent Sagas chapter considers multi-stage business processes and compensation; Tool Contract Drift covers interface semantics. Here the concern is one apparent batch submission and the actual fate of each of its constituent operations.
Choose a learning route
- Writing multiple items? Start with provider atomicity and item identities.
- Recovering a timeout? Focus on readback, exact per-item statuses and safe retry.
- Teaching Mathematics? Check the eighty-item and forty-worksheet ledgers.
- Reviewing automation? Follow authorizations, revisions, failure injection and user-facing completion.
Contents
- 1. One batch request can describe several distinct promises
- 2. Atomicity is a contract, not a convenient assumption
- 3. Per-object batch APIs can return mixed results
- 4. WebDAV’s multi-status is another explicit contract
- 5. Give each item a stable identity and expected revision
- 6. Build an item-level outcome ledger
- 7. The batch’s scope may cross several authorities
- 8. Preflight catches different problems from readback
- 9. An invented eighty-item batch laboratory
- 10. Reconciliation is safer than indiscriminate retry
- 11. Avoid hidden rollback assumptions
- 12. Transfer exercise: a forty-worksheet publishing run
- 13. Respond honestly to provider-specific mixed statuses
- 14. Test batch operations with failure injection
- 15. Practical adoption for a small team
- Frequently asked questions
- Official provider sources
- Continue reading
1. One batch request can describe several distinct promises
A batch is a grouping of operations submitted together, not automatically a database transaction. A request might contain four independent documents, ten edits to one spreadsheet or a series of deletions in storage. What happens when one member fails depends on the provider’s actual documented semantics. An agent that treats all batches as all-or-nothing can lose work, while one that treats every batch as partial can retry an already committed atomic group unnecessarily.
Define the unit of intent. A parent wants one weekly exercise report, while a publisher wants four distinct verified articles. Each desired artifact has a stable logical item ID. A batch request ID records their grouping, not their identity. This distinction helps the system avoid counting a successful transport call as four user outcomes or retrying four operations because one provider acknowledgement was incomplete.
An application can often validate certain inputs before making any remote request: required fields, expected target IDs, formatting restrictions, current approvals and duplicate logical items. This prevents obvious errors but does not prove the destination will accept the operation. The provider may reject a permission, detect a concurrent update or fail during processing. Keep preflight and actual effect separate.
Do not assume an HTTP status is the entire business answer. Some batch endpoints use an overall success code together with item-level errors, while others reject the whole request. Read the actual response body and verify the resources when the user needs a confirmed result. The assistant should not say all items succeeded solely because a JSON response was parsable.
Return to contents or continue to Atomicity is a contract, not a convenient assumption.
2. Atomicity is a contract, not a convenient assumption
An atomic operation applies the relevant changes together or none at all under the provider’s defined transaction scope. Google’s official Sheets batch requests guide says its batchUpdate subrequests are validated before execution and are applied atomically; if one is invalid the update fails rather than partially applying those subrequests. That is a concrete service-specific guarantee, not a property every API inherits from the word batch.
Even atomic application does not mean the resulting spreadsheet stays unchanged forever. Google’s documentation notes that collaborators may alter the sheet after the batch completes. Therefore, the application may need a target readback and revision context if the user’s task requires a particular final state. Atomicity is about the group as executed, not a promise that no later actor can edit it.
A database transaction may also be atomic only within its configured boundary. A spreadsheet update and a separate email notification cannot automatically share one atomic transaction merely because an agent issues them in sequence. If the first commits and the second fails, the workflow is partially complete. The controller should record that fact instead of claiming the batch rolled back everywhere.
Design documentation should name where atomicity begins and ends. The backend may guarantee all changes to one sheet but not all changes across a sheet and a remote publishing site. A model that generates a plan cannot extend the provider’s guarantee beyond what its actual service supports. If the task requires stronger coordination, it needs a specific engineered workflow.
Return to contents or continue to Per-object batch APIs can return mixed results.
3. Per-object batch APIs can return mixed results
Amazon S3’s DeleteObjects API accepts up to one thousand named object keys in one request and documents per-key Deleted and Error results. Its official examples include an HTTP 200 response containing both a successfully deleted object and an AccessDenied error for another. A client that checks only the HTTP code can mistakenly report the entire request succeeded.
S3 also documents verbose and quiet response modes. In quiet mode, successful deletions are omitted from the response while errors are returned. Interpreting an absent success item as an unattempted operation would therefore be wrong under that configured contract. The agent must understand which response mode was requested and what absence means in that mode.
Some request-level validation failures can affect the entire call. For example, S3 documents particular MFA Delete behaviours that may fail the full multi-object request. This shows why a simplistic rule such as ‘S3 always allows partial success’ would also overstate the service. The right control is a typed adapter that interprets both the overall response and item-level details for the actual version and options.
Deletion requires current authority and serious confirmation. A tool that can remove files should verify the intended objects and the user’s permission before submission; a batch convenience feature must not broaden the action to other folders. A successful item response establishes the provider’s operation result, not that the user genuinely meant to delete every named object.
Return to contents or continue to WebDAV’s multi-status is another explicit contract.
4. WebDAV’s multi-status is another explicit contract
RFC 4918 defines HTTP 207 Multi-Status for WebDAV situations where different resources need separate status codes. The recipient reads the XML response body to understand which resources succeeded, failed or require special handling. The overall status is not equivalent to one universal success condition for every member.
An AI agent may encounter a 207 response through a file-management connector. It should use a proper parser and the provider’s operation rules to map each resource to its status. The model should not improvise an interpretation from the number 207 alone. The body can contain multiple resource identities with different error codes, and a valid user-facing report may need a precise subset.
Different APIs may use HTTP 200 with JSON errors, HTTP 207 with XML resource statuses, or a single rejected transaction. There is no safe one-size-fits-all batch parser. Bind the adapter to the service’s documented semantics and test examples with mixed success before enabling consequential writes.
An overall request error can also be ambiguous. A timeout may occur before or after the destination applied changes, independent of whether the normal response would have been atomic. Reconcile real target state before resending, especially for operations such as publishing, sending messages or charging money where duplication has consequences.
Return to contents or continue to Give each item a stable identity and expected revision.
5. Give each item a stable identity and expected revision
A batch item needs more than a position in an array. Item 3 in one attempt may become Item 2 in a retry after sorting or filtering. Use a stable logical ID, target resource ID, expected version and intended action. This lets the controller match provider outcomes to actual user tasks without relying on response order unless the provider explicitly guarantees the ordering relationship.
Consider a worksheet publisher preparing four separate files. Each artifact may have its own title, content digest, current approval and intended publication state. A shared Batch B-17 can group them for convenience, but the controller should keep individual target slugs and exact expected post IDs. If one title collides with an existing post, repair that item rather than create a suffixed duplicate.
Version pinning prevents a different error. A batch may be approved at revision 4, but a model later edits a denominator in one worksheet. If the content is materially changed, prior approval may no longer authorize that exact item. The batch-level success flag cannot supply missing item-level consent. The protected executor must check the current approved payload before each consequential effect.
Stable identities also support a reliable aggregate report. Ten request attempts concerning one logical document do not equal ten published documents. Count accepted user artifacts by logical ID, and count tool calls separately for performance or cost. A system that combines these denominators can claim a higher throughput even while duplicating the same task.
Return to contents or continue to Build an item-level outcome ledger.
6. Build an item-level outcome ledger
Represent every intended item as Planned, Validated, Submitted, Verified Complete, Refused or Unknown under a specific provider and time. The exact state names may differ, but the meaning should distinguish user authorisation, transport acceptance and actual effect. A batch-level summary can be derived from those item states only after provider-specific parsing and readback.
Keep the original operation key and target ID for uncertain items. If a multi-object deletion response is lost, the controller should not generate new object IDs or assume every delete failed. For a service that treats deleting an already absent object as successful, the interpretation may differ from an action where resubmission creates a new resource. Follow each provider’s actual idempotency rules.
Separate intentionally refused items from technical errors. An unauthorised delete should remain denied, not enter an automatic retry queue. A malformed spreadsheet update may require the original payload to be corrected and reapproved. A temporary timeout might justify bounded reconciliation and a retry only if it is safe. The user should receive statuses that reflect these differences.
Store enough evidence to make the ledger audit-friendly without copying private data unnecessarily. An opaque item ID, expected revision, approved action and trusted provider receipt can establish status. A qualified reviewer may view a protected file when genuinely necessary, but normal monitoring should not broadcast the entire batch of family correspondence.
Return to contents or continue to The batch’s scope may cross several authorities.
7. The batch’s scope may cross several authorities
An agent can group tasks that share a schedule or user objective without sharing permissions. A teacher may approve one worksheet while a department editor must approve another, or a parent may authorize only a private draft. Batch execution must not infer that consent for Item A automatically covers Items B through D. Each effect needs an applicable grant.
Cross-tenant batch writes are particularly risky. A shared service account may have access to several schools, and a model might select files belonging to different accounts. Verify resource ownership at the actual target, not merely through a descriptive tenant name in the chat. One approved object should never be used as a reason to bypass a denial on another.
An external provider may validate a batch under one broad API credential. That is not the same as checking the specific human and resource permissions for every item. Application-level authorization must bind the user task to exact object identities, especially when the connector has more power than the individual requester.
Privacy and data minimisation apply to reports too. A failure summary for a batch of private student letters should not list all recipient addresses in a widely accessible alert. Keep the high-level status counts and a controlled way for authorised owners to inspect affected item IDs. Convenience does not justify publishing a sensitive batch manifest broadly.
Return to contents or continue to Preflight catches different problems from readback.
8. Preflight catches different problems from readback
Preflight validation can check schema, required fields, supported operations, exact intended target IDs, duplicate slugs and permission references. It may also check that the user has approved the current version. These checks are valuable before committing a consequential batch, but they only establish that the proposal appears valid under the local information available.
Provider execution can still fail because the resource changed concurrently, a server returned a new status or a third-party outage interrupted processing. A successful preflight does not turn those into verified completions. The next stage records the provider’s actual response, including per-item errors where the API supplies them.
Readback checks the target. For a worksheet, fetch the saved title, body, status and intended location. For a spreadsheet, inspect the relevant cells or version under the task contract. For a multi-object storage operation, use the provider’s actual object-state semantics as appropriate. A model-generated report cannot replace these observations.
Check only what the task needs, but check the actual necessary facts. One API may guarantee atomic application within the batch, reducing certain checks; another may require per-item verification. The adapter should encode those different guarantees instead of imposing redundant work everywhere or skipping necessary recovery where no guarantee exists.
Return to contents or continue to An invented eighty-item batch laboratory.
9. An invented eighty-item batch laboratory
Imagine a fictional Cedar Education Publishing Desk submitting eighty logical document changes. Fifty are independently verified complete. Twelve are correctly refused because a resource or approval is out of scope. Eight have provider-reported item-level errors needing correction. Six have uncertain effects after a lost acknowledgement. Four are held because their content revisions changed after review.
The totals reconcile: 50 + 12 + 8 + 6 + 4 = 80. The verified share is 50 ÷ 80 = 62.5%. Correct refusals are 12 ÷ 80 = 15%; item errors 8 ÷ 80 = 10%; unknown effects 6 ÷ 80 = 7.5%; revision holds 4 ÷ 80 = 5%. These are invented teaching values, not WordPress or cloud reliability measurements.
An assistant should not call the thirty noncompleted items all failures. The twelve correct refusals may protect users, while four held revisions legitimately need new review. Conversely, it must not call sixty-two items completed by counting approved-but-unsent work. Permission and final effect remain different claims. A useful ledger explains the state and next action for every item.
One transport request may include all eighty logical items, or several provider calls may be needed. The denominator here is logical document changes, not HTTP calls. The service can report request count separately for cost and latency. That distinction matters when evaluating batching efficiency: a smaller number of requests may not imply a larger number of correctly completed user tasks.
Return to contents or continue to Reconciliation is safer than indiscriminate retry.
10. Reconciliation is safer than indiscriminate retry
A timeout after a provider commits some items produces uncertainty, not evidence that all items failed. Before retrying, examine the original stable operation and the authoritative target state. A replacement attempt may need only the failed or absent items, with unchanged approvals and revisions. Blindly replaying everything risks duplicated documents or repeated emails.
Item-level error codes require classification. A permanent permission denial should not be retried with a more privileged service credential. A conflict may require a new source revision and human approval. A transient service failure can be considered for bounded retry under the provider’s rules, with attention to rate limits and shared capacity.
An apparently safe retry can still trigger new side effects. Delete operations have different semantics from Create operations; a second deletion of an absent object may be harmless under one provider, while a second create might make a duplicate. Use the actual method and response contract rather than assume identical retry safety for all batch members.
Keep the user informed in precise terms. A report might say that fifty items are verified, twelve refused, eight need correction, six await reconciliation and four need reapproval. That is more actionable than ‘batch partly worked’. It enables a qualified owner to decide which subgroup should proceed without hiding uncertainty.
Return to contents or continue to Avoid hidden rollback assumptions.
11. Avoid hidden rollback assumptions
An agent might promise to undo everything if the batch encounters one error. That promise only holds where the provider offers a suitable atomic rollback within the relevant scope, or where a tested compensation mechanism can safely restore state. Sending an email, publishing a public page and editing a sheet may not share such a boundary.
Compensation is not identical to reversal. Deleting a mistakenly published notice cannot erase copies already seen by readers, and a follow-up message cannot unsend the first. The Sagas lesson explores these distinctions. Batch-specific logic should report what was actually changed and what corrective steps remain possible.
A spreadsheet’s atomic batch may still be followed by changes from collaborators. Even if the original group applied together, later observations can differ. A rollback attempt based on an old sheet state could overwrite legitimate newer work. Use revision-sensitive updates or qualified review for affected cells, not an unconditional restore button generated by the model.
An honest postmortem can record a partial effect, the affected users, the confirmed corrective action and any remaining uncertainty. It need not claim that the world returned to its previous state simply because local files were reset. Final verification concerns real resources and people, not a convenient narrative of perfect atomicity.
Return to contents or continue to Transfer exercise: a forty-worksheet publishing run.
12. Transfer exercise: a forty-worksheet publishing run
Move the method to a fictional school planning forty worksheets. Twenty-six are independently verified published under current approval, six remain draft because editors have not authorized release, four are refused for invalid content or missing fields, two have unknown external outcomes and two were changed materially after review. The total is 26 + 6 + 4 + 2 + 2 = 40.
Verified published share is 26 ÷ 40 = 65%, while the six draft-only holds represent 15%, four invalid cases 10%, two unknown effects 5% and two changed-revision holds 5%. The fraction is an original teaching exercise, not a measure of real publishing service quality. Each class has a different next action.
Now suppose one of the two unknown publishes is found live under its original canonical post ID. The verified count rises to twenty-seven and unknown falls to one, with every other class unchanged. The total remains forty. No new publication was required; the system merely acquired evidence that the original effect occurred.
Change the content of one draft after an editor’s approval. The new worksheet differs materially from the reviewed one and should follow the organization’s applicable reapproval policy. Even if every other item in the batch passes, a broad batch-success flag must not authorize the changed document. Exact object and revision identity protect individual users.
Return to contents or continue to Respond honestly to provider-specific mixed statuses.
13. Respond honestly to provider-specific mixed statuses
An HTTP 200 from S3 multi-object delete is compatible with an Error entry for one named key. A Google Sheets batchUpdate rejection can mean none of its validated subrequests applied. A WebDAV 207 response requires per-resource status inspection. These are different semantics documented by different providers. The controller should select a typed adapter, not ask the model to guess from the status-code number.
Use strict parsing for each provider response. Unexpected fields or enum values should lead to a safe unresolved state, not mapping them to success. If a provider changes the contract, verify the new meaning before executing more consequential work. A program that swallows item-level errors to simplify the UI may be fast but cannot support truthful completion claims.
Present a clear end-user summary linked to actual artifacts. A parent might care that the Mathematics worksheet was saved and accessible, not that an HTTP request succeeded. A staff editor may need the four failed item IDs and reasons. Different user roles can receive different views while the underlying ledger preserves one authoritative result.
Good explanation does not replace safe execution. A fluent assistant could correctly describe atomicity while using the wrong resource ID. Check current permission, actual target and saved state. Reliable batch work is both a contract interpretation problem and an externally verified action problem.
Return to contents or continue to Test batch operations with failure injection.
14. Test batch operations with failure injection
Build an isolated fixture containing several fictional resources with stable IDs and known versions. Have the mock provider accept the batch, reject one item, time out after a partial effect and return an unrecognized status. Then ask whether the agent can classify each item without duplicating actions. The expected answers come from the simulator’s actual state, not its conversational summary.
Include a truly atomic mock path and a per-item mock path. In the atomic case, an invalid subrequest should leave every target unchanged under the declared contract. In the per-item case, some changes should occur while others fail. The test verifies that the adapter does not apply a universal interpretation to both. This is more powerful than testing only the happy path.
Test authorization and content revision too. A batch of four worksheets should not publish one whose grant expired or whose approved draft was materially changed. A denial is correct even if it reduces throughput. A positive control confirms a permitted unchanged worksheet can still complete once and be independently read back.
Preserve failing cases as regression fixtures after repair. A model upgrade or provider schema change can reintroduce a status-mapping error. The suite should test actual saved effects and the integrity of the ledger. A green report generated by the assistant itself is not proof of batch completion unless the independent oracles agree.
Return to contents or continue to Practical adoption for a small team.
15. Practical adoption for a small team
Start by listing every batch-like operation the service uses and the provider-specific response contract. Record whether the batch is atomic, partly independent, asynchronous or subject to special request-wide failures. Bind each item to a stable task and target identity. Keep batch grouping as an optimization rather than the source of human authority.
Build a simple ledger with planned, submitted, verified, refused and unresolved states. Add preflight checks for current permission, expected revision and item shape. After sending, parse per-item results where relevant, independently inspect the necessary target records and reconcile ambiguous effects before retrying. Do not invent statuses from one general HTTP code.
Measure both resource cost and user value. One well-designed batch may reduce request overhead, but a failed item still needs a real response. Report verified artifacts per intended task, partial outcome categories, duplicate rates and human review obligations, each with named denominators. Good performance is lower effort for correct useful results, not a large pile of submitted requests.
The core lesson is that a batch is a container for intentions, not proof they all came true. Students can check the forty-worksheet arithmetic; editors can see which items need attention; engineers can preserve exact target identities and safe retries. A powerful model becomes dependable only when the surrounding system verifies each actual effect.
Return to contents.
18. Atomic execution and asynchronous completion are different
An API can apply a set of database changes atomically and still expose an asynchronous user workflow that is unfinished. For example, a school might atomically update four rows of an internal sheet while an external publication service independently queues notifications. The sheet’s guarantee does not extend to that notification system. A truthful report names the precise resource where all-or-nothing behavior is guaranteed and marks other effects as pending until they are checked.
Conversely, a provider might acknowledge a batch job’s acceptance without yet applying its items. The application must not convert Queued into Complete because the HTTP response was successful. Use operation-level IDs and eventual item-level readback or final receipts. When confirmation is unavailable, preserve Unknown. A model’s desire to finish the conversation cannot change what the destination has actually committed.
The strongest practical architecture records each item’s intended final state before submission. After the provider acts, compare that intended state with the observed state under the current approval and source revision. This avoids relying solely on how an HTTP envelope was named and makes the user-facing result comprehensible: which worksheets were actually saved, which were refused, and which still need verification.
Return to contents for related batch controls.
19. Provider quiet modes demand deliberate interpretation
Amazon S3’s multi-object delete quiet mode returns errors while omitting successful individual results. A naive client might think absent `Deleted` elements mean that the service did not try those keys. The documented response convention says otherwise. A batch adapter should carry the request’s mode into the response parser and distinguish a missing response field under a defined contract from an entirely missing response.
An overall transport timeout is a different situation because the agent may have no trustworthy body to interpret at all. The request could have failed before reaching the provider or completed despite loss of its acknowledgement. The controller needs to reconcile known object keys or operation IDs, not infer a negative outcome from silence. A provider-specific reconciliation API or resource readback can settle some cases.
Some delete requests receive a successful result for an object that was already absent. That can be appropriate under the service’s documented semantics, but the agent should not claim that it personally removed a previously existing file without evidence of that earlier state. Distinguish the requested final condition from the historical event of deletion. Exact words matter when users are auditing access or data retention.
Return to contents for related batch controls.
20. Keep the original user intent through error repair
A malformed item may need correction before it can be resubmitted. The repair should not silently change its target account, destination, privacy scope or approved content. The fact that it appeared in a batch of permitted tasks does not authorize it after a material revision. Attach a versioned source and human approval to the individual item, and ask for renewed approval when the policy requires one.
Imagine a batch of four articles in which one attempted slug already belongs to a published page. Creating another post with a suffixed slug might technically succeed but not fulfil the user’s canonical URL expectation. A safer process checks for the original stable owner, verifies content and decides whether an approved update to that page is appropriate. The other three complete articles need not be republished.
Distinguish the permission error from a repairable formatting error. A bad field name can be corrected under a known tool contract, while an AccessDenied result should not trigger an administrator-credential fallback. Successful batch recovery means preserving the user’s actual authority, not exhausting every available way to force an effect.
Return to contents for related batch controls.
21. One safe progress report across partial outcomes
Readers benefit from a compact status report that gives verified item counts and meaningful distinctions. An invented batch with fifty verified completions, twelve correct refusals, eight provider item errors, six uncertain effects and four changed-version holds totals eighty. Show the five classes rather than one arbitrary success percentage. The numbers remain fictional and are intended to teach conservation of a task population.
After one of the six unknown outcomes is independently confirmed complete, verified becomes fifty-one and unknown becomes five. The other categories remain unchanged, so 51 + 12 + 8 + 5 + 4 = 80. This update does not involve a second publication. It reflects newly obtained evidence for the earlier operation and should not overwrite the historical cutoff.
Count user artifacts separately from HTTP requests. A single batch transport could create several item receipts, while repeated transport attempts might refer to the same logical item. Service value is measured by independently verified intended results under the right user permission, not the number of API calls or error messages collected.
Return to contents for related batch controls.
22. Permission boundaries remain item-specific
Some source systems accept one batch under a broad service identity. That authentication may be necessary for access to the endpoint but cannot establish that every individual file belongs to the requesting user. Apply trusted object and operation authorization before execution and, where supported, at the destination itself. A model-generated reason for accessing another tenant’s file is not a policy grant.
An item that was permitted when planned can become ineligible after cancellation, expiry or revision change. A queue delay should not allow a stale approval to authorize a new external effect. The batch executor needs effective time and current source state for each item. The surrounding service may allow independent safe items to proceed while holding those with missing authority.
Use synthetic tests for mixed permissions. Give a fictional Cedar School user three permitted worksheet objects and one Willow School private record in the same proposed batch. The protected service should refuse the Willow item without leaking its contents. If the provider’s operation is atomic, it may instead reject the entire group; the expected result must match the actual contract and business policy.
Return to contents for related batch controls.
23. Verification evidence can remain privacy-conscious
An agent does not need to record the entire private file contents in every success event to establish completion. Store intended target IDs, approved revision and the provider’s authoritative status under appropriate access controls. A qualified editor can inspect the actual artifact from its protected source when necessary. This keeps the audit trail useful while avoiding a duplicate repository of sensitive student work.
A user-facing report may disclose safe artifact links for verified public articles but should not expose private documents or internal error payloads from other accounts. The ability to produce several links at once does not change their access classification. Keep public publication and private draft states distinct even within the same batch.
A checksum can help verify that saved bytes match an approved version when the underlying system supports a trustworthy digest. It cannot by itself prove the human granted publication or that the source facts are correct. Link payload integrity with current approval and target-state readback, each backed by the proper trusted service.
Return to contents for related batch controls.
24. Release gates for batch-capable agents
Before enabling batch writes, test invalid input, partial provider responses, asynchronous statuses, item-level permission denials, source revisions and timeouts. Use both positive and negative synthetic cases. The system should complete permitted items according to the provider semantics and refuse or hold ineligible ones without inventing a whole-batch guarantee.
After a provider SDK or schema changes, rerun the contract tests. A response formerly containing one result array might introduce a new error field or a different quiet mode, altering how status should be interpreted. A strict adapter must recognize the documented version and leave unknown values unresolved until reviewed. The model cannot infer new semantics merely from field names.
An accountable release includes a human correction route for mistaken results. A user should be able to identify the particular file that failed, request a safe retry or challenge a wrong target without resubmitting all work. Safe batching reduces overhead while preserving individual agency, permission and independently verified completion.
Return to contents for related batch controls.
- 18. Atomic execution and asynchronous completion are different
- 19. Provider quiet modes demand deliberate interpretation
- 20. Keep the original user intent through error repair
- 21. One safe progress report across partial outcomes
- 22. Permission boundaries remain item-specific
- 23. Verification evidence can remain privacy-conscious
- 24. Release gates for batch-capable agents
Frequently asked questions
Do all batch APIs succeed or fail as one transaction?
No. Google Sheets documents atomic batchUpdate, while S3 DeleteObjects can report individual successes and errors. Read the actual provider contract.
Can HTTP 200 contain a failed item?
Yes. Amazon S3 documents a multi-object delete response with overall 200 and per-object Error entries.
What does WebDAV HTTP 207 mean?
A Multi-Status response whose body contains per-resource status information; it is not a universal whole-batch success claim.
Should the agent retry an entire batch after a timeout?
Not blindly. First reconcile the original operations and affected target resources to avoid duplicates.
Can one approval authorize every item in a batch?
Only if the actual grant covers those exact items and versions; batching cannot create missing permissions.
Does an atomic write guarantee no subsequent changes?
No. Later collaborators or external services may change resources, and atomicity has a defined scope.
Official provider sources
Sources reviewed 24 October 2026. All Cedar Education records, counts, permissions and batch outcomes are fictional, not live measurements. Provider guarantees must be checked against the actual method and configuration.
- Google Sheets Batch Requests: Atomic subrequest validation and execution under its specific API.
- Amazon S3 DeleteObjects: Per-object results, quiet mode and request-wide exceptions.
- RFC 4918 WebDAV Multi-Status: HTTP 207 resource-level status semantics.
- PostgreSQL Transactions: Atomic commit and rollback within a database transaction.
- OWASP Authorization: Current permission at protected resource boundaries.
Continue reading
Continue through Super Intelligence curriculum; Agent Sagas; Tool Contract Drift; Dual Control; Data Export. A batch is useful only when each intended object has an authorised and independently verified outcome.