Henry deep dive

This page is the deep dive on how Henry is built. It is paired with Oswald deep dive on the editorial side. Henry’s defining property is the read-only boundary; everything else flows from that.

​

The shape of Henry

Henry is a system that combines:

1. A customer-supplied AI provider. OpenAI or Gemini. Brand Atlas does not run the model; the customer’s account does.
2. A system prompt. Brand Atlas’s instructions to the model, defining Henry’s behaviour and constraints.
3. Brand-record grounding. The atlas’s content, supplied to the model at each interaction, scoped to what the asking user can read.
4. No tool-use loop with write tools. Henry can read; Henry cannot write.
5. Conversation memory per session. Within a session, Henry remembers context. Between sessions, memory is fresh.
6. Citation in every answer. Henry’s responses cite the section, the line, or the request the answer is drawn from.

​

The read-only boundary, in detail

The read-only boundary is enforced at three layers:

1. The system prompt. Henry is instructed that it cannot edit the brand record, cannot create Update Requests on behalf of the user, cannot generate Guest Passes, cannot create Horizons. The instruction is explicit and reinforced.
2. The tool set. Henry is given read tools (search, read_section, read_history) and not given any write tools. The tools Henry uses are the only tools Henry has.
3. The application layer. Brand Atlas’s API rejects any write-shaped request from a Henry session, regardless of how the request was formed. The boundary is defended in code, not just in instruction.

The three layers together mean that even an adversarial prompt cannot get Henry to write. The model can be asked anything; the architecture refuses to act on writes.

​

Scoped read access

Henry’s read access is scoped to what the asking user can read. A team member talking to Henry can only get Henry to surface material the team member already has rights to. A Guest talking to Henry (where the Guest Pass permits Henry use) can only get Henry to surface material within the pass scope. This is enforced at the same three layers as the write boundary: in the system prompt, in the read tools (which take the user’s role as a parameter), and at the application layer (which filters responses against the user’s permissions).

​

Conversation memory

Within a session, Henry remembers the conversation. The team member can ask a follow-up question without re-stating the context: what about the dark variant? after a question about logo usage. Henry knows the conversation is about logos. Between sessions, Henry starts fresh. There is no long-term memory; Henry does not remember the question the user asked last week. The default session window is the current conversation, from open to close. Closing the panel ends the session; a new panel open starts a new session. For Guardian customers, the session window can extend to “until reset by the user,” meaning the conversation persists across panel-open events. Useful for users who want continuity across the day. The setting is per-user.

​

Citation behaviour

Every Henry response includes citations. A citation contains:

• The section name (e.g. “Colour System”).
• The specific element if relevant (e.g. “Primary Blue swatch”).
• A link to the section.

Citations are how the team can verify Henry’s answers. The team member who reads an answer and is unsure can click the citation and check the brand-record material directly. When Henry is unable to find a definitive answer in the brand record, the response says so: the brand record does not document this; you may want to raise an Update Request. The transparency is more useful than confident hallucination.

​

What is sent to the provider

Each Henry interaction sends to the customer’s provider:

• The system prompt.
• The brand-record context relevant to the question (grounding).
• The conversation so far in the session.
• The user’s prompt.

The provider returns the response. Brand Atlas processes it and presents to the user. What is not sent:

• Other atlases the user has access to.
• The plaintext form of any secrets stored in the atlas.
• The team’s email, calendar, or external system data.

The provider stores the request and response according to its enterprise terms. Both OpenAI and Gemini’s enterprise tiers do not use API content for training. Standard latency-purposes retention applies (typically 30 days), then the data ages out.

​

The grounding model

Henry receives the brand-record context as part of the prompt sent to the provider. The context is:

• The Glossary.
• The standard sections relevant to the question.
• Active Horizons relevant to the question.
• Recent Update Request history relevant to the question.

The relevance is determined by Henry’s read tools: a search across the record, retrieval of the most-relevant sections, and selective expansion based on the conversation context. The grounding model has two consequences worth understanding:

• Henry’s answers are traceable. Every claim Henry makes can (and should) be tied to a citation.
• Henry knows what it does not know. When the record is silent, Henry says so.

​

The cost model

Each Henry interaction has a cost in tokens (input + output) at the provider’s rates. The customer is billed by the provider at the end of the billing period. Brand Atlas does not mark up the AI cost. Brand Atlas’s revenue is the Keeper or Guardian subscription. The provider’s bill is the customer’s responsibility. A useful estimate: a single Henry question and response is typically 1,000 to 3,000 tokens combined. At current OpenAI and Gemini rates, that is a fraction of a cent. A heavy team using Henry several hundred times a day might see usage in the tens of dollars per month; a typical team is closer to $10-20.

​

Rate limits

Henry inherits the rate limits set by the customer’s provider account. If the team exhausts the provider’s per-minute rate limit, Henry returns a rate-limit message and asks the team member to retry shortly. Brand Atlas does not set its own per-team rate limit on top. For Guardian customers running high volume, configure a higher rate limit with the provider or use the dedicated tier their account permits.

​

Provider failover

Henry is configured with a single provider per atlas. If the provider has an outage, Henry is unavailable for the duration. There is no automatic failover to a different provider; failover would require duplicating the key arrangement and the customer’s setup. If your team’s tolerance for Henry downtime is low, the right answer is to have a tested second key from the alternative provider, ready to paste in during an outage. See Switching providers.

​

Related pages