Oswald deep dive

This page is the deep dive on how Oswald is built. It is written for the brand owner who wants to understand the system behind the assistant they are approving drafts from. The page does not require any technical background, but it is more detailed than the other Oswald pages.

​

The shape of Oswald

Oswald is a system that combines:

1. A language model. The underlying engine that generates text. Currently Anthropic Claude on a vendor-hosted enterprise tier with no training on customer data.
2. A system prompt. The instructions that shape what Oswald does and how it responds. Authored by Brand Atlas and held private; the behaviour it produces is public.
3. Brand-record grounding. The atlas’s own content, supplied to the model at each interaction.
4. A tool-use loop. The structured sequence of read / draft / present / apply.
5. An audit layer. The recording of every interaction in the brand record’s history.

Each of these is operational. Removing or changing any of them changes Oswald’s behaviour. The decision about what each layer should be is Brand Atlas’s, not the underlying provider’s.

​

What grounding means

Oswald is grounded in the brand record. At each interaction:

• Oswald reads the relevant brand-record material before drafting.
• Oswald cites which material it read in its read confirmation.
• Oswald’s draft uses the material’s actual values (the current palette, the current typography, the current voice rules) rather than approximations.
• When the brand record is silent on something, Oswald says so, rather than inventing.

Grounding is the difference between Oswald and a generic AI assistant. The same prompt to a generic assistant produces plausible-sounding but unverified output. The same prompt to Oswald produces output traceable to the brand record.

​

The prompt-cache breakpoint

The brand record is the same between Oswald sessions. Sending it fresh on every interaction would be wasteful. Oswald uses a prompt cache: the brand record is encoded once and reused across sessions until the record changes.

• Cache hit. Oswald responds faster and cheaper. Most sessions are cache hits.
• Cache miss. Triggered when the brand record has changed since the last cached version. Oswald re-encodes the relevant material. The first session after a substantial brand record edit is slightly slower; subsequent sessions are back to fast.

The breakpoint is set at the brand record level: changes within a section invalidate the cache for that section’s neighbourhood; changes to the standard sections invalidate broader portions. The user does not need to manage the cache; it just works.

​

The tool-use loop, in detail

A tool-use loop is a pattern where the AI does work in steps, each of which can be inspected and (in some cases) overridden. Oswald’s loop has five tool types:

1. read_section. Read a specific standard section or Horizon.
2. read_history. Read the recent history of a section.
3. search_record. Full-text search across the brand record.
4. draft_change. Produce a proposed change to a specific section or Horizon.
5. apply_change. Apply an approved change. Requires explicit brand-owner confirmation.

For a single Update Request response, Oswald might call read_section two or three times, search_record once, and draft_change once. The brand owner sees each call in the panel. apply_change runs only on confirmation; the brand owner sees the exact diff and approves before the call happens. There is no way to chain draft_change directly into apply_change without the confirmation step. This is by design and not configurable.

​

Limits on the tool-use loop

Three limits in production:

1. Steps per session. A single session can contain up to 20 tool calls. Beyond that, Oswald summarises and asks the brand owner whether to continue. Most sessions use 3 to 8 calls.
2. Token budget per session. A standard cap that prevents runaway sessions. The cap is more than enough for any normal use; if hit, Oswald reports it and waits for the brand owner.
3. Concurrent sessions per atlas. Up to 3 concurrent Oswald sessions per atlas. Multiple brand owners or editors using Oswald simultaneously share the cap.

These limits exist primarily as guard rails against unexpected behaviour. They are not visible in normal use.

​

How Oswald handles ambiguity

Oswald can ambiguously interpret a prompt in two main ways:

• The prompt is genuinely ambiguous. Oswald asks a clarifying question rather than guessing.
• The brand record is ambiguous. Two sections of the record could apply, with different implications. Oswald flags the ambiguity in its draft, names both possibilities, and asks the brand owner to choose.

Ambiguity is not error. The brand record is sometimes intentionally underdetermined; the brand owner’s choice fills the gap. Oswald surfacing the ambiguity is the right behaviour.

​

What is sent to the provider

Each Oswald interaction sends to the underlying provider:

• The system prompt (Brand Atlas’s, not visible to the customer).
• The brand-record context relevant to the interaction (grounding material).
• The brand owner’s current prompt and any attached content.
• The conversation so far in the current session.

The provider returns the model’s response. Brand Atlas processes the response, runs any tool calls, presents the result. What is not sent:

• Material from other atlases (every atlas is isolated).
• Material outside the atlas (no email, no calendar, no external integrations).
• Identifying information beyond what the brand record itself contains.

The provider’s enterprise terms (no training on API content; no long-term retention) apply. The full disclosure is in AI Usage & Disclosure Policy.

​

The audit layer

Every Oswald action is logged. The audit record contains:

• The prompt. The brand owner’s input.
• The tool calls. Every read, search, draft, and apply.
• The model’s response. What Oswald produced.
• The brand owner’s edits. If the draft was edited before applying.
• The final outcome. Approved, rejected, escalated, applied, abandoned.

The audit is part of the brand record. It is retained according to the tier’s history retention.

​

Changing the underlying model

The underlying language model may change over the life of the product. A better model becomes available; the provider relationship changes; a different model proves better at a specific task. When the model changes:

• The branding (Oswald) does not change.
• The system prompt is reviewed and adjusted if needed.
• The workflows do not change.
• The customer is notified through the changelog.
• The disclosure policy is updated.

The customer’s relationship with Oswald is stable. The underlying engine is plumbing.

​

Related pages