Oswald and Update Requests

On Guardian, Oswald can draft a response to an Update Request. The brand owner clicks Draft with Oswald on an open request; Oswald reads the relevant brand-record context; Oswald produces a draft change; the brand owner reviews, edits, and approves. The decision is the brand owner’s at every step. The implementation is Oswald’s. This page mirrors Update Requests with Oswald from the AI tab. The two pages cover the same flow from different angles: the Update Requests page documents how it shows up in the workflow; this page documents how Oswald is operating.

​

The tool-use loop

Oswald drafts an Update Request response through a tool-use loop: a sequence of explicit steps the brand owner can observe and intervene in. The loop runs:

1. Read the request. Oswald reads the team member’s proposal, reason, and any attachments.
2. Read the current state. Oswald reads the section the request concerns, plus any sections the request references.
3. Read the related history. Oswald reads recent changes to the affected section and recent Update Requests on the same section, to avoid re-drafting something the brand owner has already decided against.
4. Draft the proposal. Oswald produces a specific change against the brand record.
5. Present. Oswald shows the draft alongside the current state, with reasoning.
6. Wait. Oswald does nothing further until the brand owner acts.
7. Apply on confirmation. If the brand owner approves and confirms, Oswald applies the change. If the brand owner edits, the edited version is applied. If the brand owner rejects or escalates, Oswald closes the session.

Each step is visible. The brand owner can pause, edit Oswald’s working assumptions, or take over at any step.

​

Confirmation points

Two explicit confirmation points are not negotiable in the loop:

1. Brand-owner approval of the draft. Oswald does not apply on its own initiative. Every apply requires brand-owner approval.
2. Brand-owner confirmation of the apply. Even after approval, the apply runs through a final confirmation: “Apply this change to the brand record?” Yes runs the apply; no returns to the draft.

Both confirmations are unskippable by design. Some workflows trade off this kind of friction for speed; in Update Requests, the friction is the point. Authorship is the asset.

​

What Oswald reads when drafting

Oswald reads:

• The request itself. Proposal, reason, attached files.
• The current state of the affected section or Horizon.
• Any sections explicitly referenced by the request.
• Recent edits to the affected section (last 90 days).
• Recent closed Update Requests on the same section (last 90 days, with outcome).

Oswald does not read:

• The team’s email or chat.
• The brand owner’s calendar.
• External documents not attached to the request.

The brand record is the universe; the request is the prompt.

​

What appears in the audit trail

Every Oswald-drafted response leaves an audit trail in the brand record:

• Oswald’s read summary. What Oswald read before drafting.
• The draft. Oswald’s proposed change.
• Brand-owner edits, if any. The diff between Oswald’s draft and the final applied version.
• Brand-owner approval. Timestamped.
• The apply. The change as it landed in the brand record.

The trail is visible in the request’s history and in the brand record’s history.

​

Editing the draft

The brand owner can edit Oswald’s draft inline before applying. Common edits:

• Tighten the wording. Oswald drafts in the brand’s voice; humans tighten further.
• Adjust the scope. Oswald drafts to the request; humans sometimes apply a narrower or wider change.
• Add a “don’t” example. Oswald drafts the addition; humans add the negative example.
• Note the reasoning for the brand record. A note explaining why the change was made.

Edits are not lost when the apply runs. The edited version is what lands.

​

When Oswald asks for clarification

Oswald asks for clarification when:

• The request is ambiguous.
• The brand record is silent on a question the response requires.
• The request implies a decision Oswald is not configured to make (a strategic call, a financial commitment).

The clarification is a single question, asked in the same panel. Answering the question continues the draft. The clarification exchange is part of the audit.

​

When Oswald gets it wrong

Oswald will produce wrong drafts sometimes. Common patterns:

• Drafting against an out-of-date section. The brand record has a section that contradicts something more recent. Update the record, then ask Oswald to redraft.
• Misreading the team member’s intent. The proposal was ambiguous; Oswald guessed wrong. Edit the draft to match the actual intent, or reject and ask the team member for clarification.
• Applying a rule too rigidly. Oswald flags a deviation from voice when the deviation was deliberate. Approve the variation rather than fixing it.

In each case the brand owner overrides cleanly. The override is recorded; Oswald’s future drafts on similar prompts may improve from the pattern.

​

Disabling per-request

If the brand owner does not want Oswald involved in a specific request, simply do not click Draft with Oswald. The standard manual flow remains available. Oswald never participates without explicit invitation.

​

Disabling globally

Settings → AI → Oswald → Available on Update Requests. Toggle off. Oswald remains available for Build-with-Oswald, asset review, and other uses; the request panel no longer offers Oswald drafting.

​

Related pages