Enter password to view

[ actual intelligence ]

actual

intelligence

CONTEXT FORGE / OPERATING CONTEXT

OPERATING CONTEXT

Gathering per-user context for optimal agentic builds

AI agents are only as useful as the per-user operating context they are able to access, interpret and treat as their Source of Truth. That confidence and specificity shapes the agentic build itself.

AI agents are only as useful as the per-user operating context they are able to access, interpret and treat as their Source of Truth. That confidence and specificity shapes the agentic build itself.

The first principle

Generic agents fail when they do not understand the executive’s real context: judgment standards, communication preferences, source boundaries, stakeholder obligations, recurring pressures, and what must never be inferred or promised.

The Context Forge method

Context Forge captures operating context through guided spoken sessions, controlled source intake, and reviewable evidence states. The process separates portable professional judgment from current-role material, overlap, hold, delete, and off-limits content.

The capture protocol

A structured Superwhisper-powered surface prompts one question at a time, captures spoken answers as segmented context, supports bookmarks, retakes, topics, asides, and continuation points, then routes material into reviewable states before it becomes durable context.

From context to agents

The platform does not start by asking which agents a person wants. It captures the expectations and demands placed on them, identifies recurring burdens and judgment gates, then designs bespoke agents only where the evidence proves they should exist.

Per-person agent portfolios

One executive may need customer expectation-risk review. Another may need board-prep synthesis, delegation-return-loop monitoring, proposal evidence-gap analysis, or style-safe communication drafting. The useful portfolio emerges from the person’s operating reality.

At enterprise scale

Individual operating assets remain private and permissioned, while approved organizational layers can compound: shared templates, review gates, role taxonomies, source-use rules, communication standards, workflow patterns, and aggregated friction signals.

The operating-context method

01

Capture

Guided spoken answers and approved source material.

02

Structure

Portable, role-bound, overlap, hold, delete, and off-limits states.

03

Infer

Repeated burdens, judgement gates, risks, and open loops.

04

Design

Bespoke agents with source rules and review gates.

05

Prove

Before/after output improvement and reduced cognitive load.

Why it matters

Executives carry high-value tacit context that generic AI cannot safely infer. Structured capture turns that context into a private operating asset, so agent design becomes evidence-led rather than speculative.

Current proof path

Build one complete executive operating asset. Use captured context to improve real outputs. Document the repeatable method before enterprise translation.

The Context Forge Question Architecture

These questions were rewritten to make the capture process feel less like an interview and more like a private calibration session for building useful executive agents.

The intent is to help the system learn how your work actually reaches you, what genuinely needs your judgment, what should stay visible without living in your head, what can be prepared before it reaches you, and what must remain private, role-bound, or off-limits.

The main standards applied were:

  • Concrete before abstract: Each section starts from a recent real example, not a theory of how you work.

  • Low threat: The wording avoids anything that sounds like evaluation, assessment, productivity review, or delegation critique.

  • Time respect: Questions are designed to be answerable quickly by voice, without preparation.

  • User control: You can answer partially, stay at pattern level, skip anything sensitive, mark material off-limits, or hold it for review.

  • Operational usefulness: Every answer should help create a future agent behavior, boundary, review gate, memory object, or workflow rule.

  • Enterprise fit: The questions are being tested not only for you, but for whether a skeptical, time-poor Nvidia executive would understand them, trust them, and answer usefully.

The central design principle was: the questions are not just intake. They are the trust surface through which the eventual system earns the right to be useful.

A clearer way to map what should stay with you

Use these prompts as a calm inventory of judgment, load, delegation, safety, and the first useful operating surface. Each block is designed to capture one durable pattern without forcing every detail into memory.

Use these prompts as a calm inventory of judgment, load, delegation, safety, and the first useful operating surface. Each block is designed to capture one durable pattern without forcing every detail into memory.

Use these prompts as a calm inventory of judgment, load, delegation, safety, and the first useful operating surface. Each block is designed to capture one durable pattern without forcing every detail into memory.

Session 1 | Structure And Scope

Session 1 | Structure And Scope

01

Responsibility Landing Points

Responsibility Landing Points

01/01/01

Think of a recent message, meeting, request, or thread that ended up back with you. What was happening, in plain terms?

01/01/02

What made it land with you rather than keep moving elsewhere?

01/01/03

What part, if any, genuinely needed your judgment?

01/01/04

What could someone or some system have prepared, summarized, drafted, or moved forward before it reached you?

01/01/05

What needed to stay visible, even if it did not need to stay in your head?

01/01/06

Is this example mostly about your durable way of operating, your current role, both, or something that should be kept out of the system?

01/01/07

If the system saw something similar later, what should it do before trying to help?

02

Current Operating Load

Current Operating Load

01/02/01

Think of a recent day, trip, week, or meeting cluster where the load became hard to hold. What was the situation?

01/02/02

What were the main things competing for attention: messages, meetings, travel, deadlines, follow-ups, decisions, people waiting on you, or something else?

01/02/03

Which parts genuinely mattered, and which parts were mostly loud, repetitive, or time-sensitive?

01/02/04

What were you forced to remember manually?

01/02/05

What became hard to keep visible even though it still mattered?

01/02/06

Where did travel, time zones, meeting density, or context switching make the situation harder?

01/02/07

If the system could have reduced one piece of that load without creating new work for you, what should it have handled first?

03

Judgment Boundaries

Judgment Boundaries

01/03/01

Think of one recent situation where something needed your judgment before it could responsibly move forward. What was happening?

01/03/02

What made it unsafe, premature, or inappropriate for someone else to decide alone?

01/03/03

What context did you need before you could answer responsibly?

01/03/04

What could have gone wrong if someone had answered too quickly?

01/03/05

What could someone else have prepared, even if the final judgment still needed to stay with you?

01/03/06

What signal would tell the system that this needs to rise above ordinary urgency?

01/03/07

If the system saw this pattern later, should it prepare, ask, hold, escalate, draft, or stop?

04

Work That Leaves and Comes Back

Work That Leaves and Comes Back

01/04/01

Think of one recent piece of work that moved away from you and stayed away. What made that possible?

01/04/02

Now think of one piece of work that moved away but came back. What brought it back?

01/04/03

What should the system notice about the difference between those two cases?

01/04/04

What kinds of work need your approval but not your execution?

01/04/05

When someone else owns the next move, what still needs to remain visible to you?

01/04/06

When should something leave your field of view entirely?

01/04/07

If the system saw work leave your hands, what should it track, remind, hide, or ask before resurfacing?

05

Boundaries and Safety

Boundaries and Safety

01/05/01

What kinds of material are clearly off-limits?

01/05/02

What kinds of material may be discussed at pattern level but not stored?

01/05/03

What kinds of material may be summarized but not copied?

01/05/04

What kinds of material, if any, should only be used locally or temporarily?

01/05/05

What kinds of drafting would be useful but should always require your explicit review before use?

01/05/06

What actions must the system never take without asking?

01/05/07

Is there employer-bound material that might still produce a portable principle if abstracted and approved?

01/05/08

Where are you unsure enough that the safe answer is hold for review?

06

First Operating Surface

First Operating Surface

01/06/01

If this were useful within one week, what pressure would it reduce first?

01/06/02

Which first surface sounds closest: what needs judgment today, what loops are still open, what meetings need preparation, what follow-ups were created, what drafts need review, or what risks need checking?

01/06/03

What should be visible immediately?

01/06/04

What should stay hidden unless you ask for detail?

01/06/05

What would make the first output feel trustworthy rather than clever?

01/06/06

What would make you reject it immediately?

01/06/07

What should the system ask you before taking the next step?

Session 2 | Judgement And Standards

Session 2

Judgement And Standards

01

Decision Standards

02/01/01

Think of a recent case where something was good enough, clear enough, and appropriately framed enough to send, share, delegate, approve, or move forward. What was happening?

02/01/02

What made it good enough to proceed?

02/01/03

What could still be imperfect without stopping it?

02/01/04

Now think of a recent case where something had to be held back. What was happening?

02/01/05

What was missing or unresolved?

02/01/06

Was the issue missing information, unclear framing, unresolved authority, relationship sensitivity, risk, or something else?

02/01/07

What signals usually tell you something is premature?

02/01/08

What signals usually tell you something needs escalation?

02/01/09

What must be correct before anything proceeds?

02/01/10

If the system saw a similar situation later, what should it check before recommending that something move forward?

02

Sufficiency, Risk, and Delegation

02/02/01

Think of one recent item that moved forward quickly and safely. What made it safe to move?

02/02/02

What made it sufficient, even if it was not perfect?

02/02/03

What would have made that same item unsafe to move?

02/02/04

Now think of something that looked finished but still should not have proceeded. What was happening?

02/02/05

What judgment, context, ownership, relationship sensitivity, or authority was still unresolved?

02/02/06

Think of a delegated item that came back to you. What brought it back?

02/02/07

Was it missing components, missing context, missing authority, or missing your judgment?

02/02/08

What kind of decision should stay with you even when the materials are complete?

02/02/09

What can someone else prepare or execute while the final judgment remains yours?

02/02/10

If the system saw this pattern later, what should it prepare, hold, escalate, or ask before proceeding?

03

Communication Standards

02/03/01

Think of a recent message, draft, update, proposal section, or note that felt right to you. What made it work?

02/03/02

What should the system notice in writing that feels representative of you?

02/03/03

Think of a recent message or draft that was technically accurate but still felt wrong. What was wrong with it?

02/03/04

What usually makes an assisted response sound unlike you?

02/03/05

What tone do people expect from you in high-stakes communication?

02/03/06

When do you prefer direct language?

02/03/07

When do you deliberately soften, qualify, or defer?

02/03/08

What kinds of phrasing create unnecessary exposure, overcommitment, or concern?

02/03/09

If you were sharing writing samples, what should be usable as a pattern, what should stay role-bound, and what should remain off-limits?

02/03/10

If the system drafted in your voice later, what should it ask or check before showing you the draft?

04

Risk Sensitivity

02/04/01

Think of a recent situation where a response could have created risk if it were worded, timed, or framed badly. What was happening?

02/04/02

What risk would a bad response have created?

02/04/03

What kinds of commitments should never be made casually?

02/04/04

What should be acknowledged without being promised?

02/04/05

What should be described as exploratory, provisional, or pending validation?

02/04/06

What kinds of uncertainty should be made explicit?

02/04/07

What must be reviewed before being sent, shared, delegated, or closed?

02/04/08

Where do people usually underestimate the risk?

02/04/09

What signal should make the system hold rather than proceed?

02/04/10

If the system saw a similar situation later, what should it say, ask, or refuse to do?

05

Completion Standards

02/05/01

Think of a recent piece of work that was truly done. What made it complete?

02/05/02

What evidence showed that the loop could close?

02/05/03

Think of something that looked done but still had an open loop. What was unresolved?

02/05/04

Was it unfinished because components were missing, confirmation was missing, authority was missing, or judgment was still required?

02/05/05

When is a reply enough?

02/05/06

When does completion require confirmation from someone else?

02/05/07

When does a delegated item remain visible to you?

02/05/08

When should the system ask whether something can be closed?

02/05/09

What should prevent the system from treating something as complete?

02/05/10

If the system saw a similar loop later, what evidence should it require before suggesting closure?

06

Trust and Rejection Signals

02/06/01

Think of a recent output, draft, summary, or recommendation that felt immediately usable. What made it usable?

02/06/02

What makes you trust that the system understood the situation?

02/06/03

What makes you distrust an output even if it is grammatically good?

02/06/04

What kinds of mistakes are tolerable?

02/06/05

What kinds of mistakes are unacceptable?

02/06/06

When should the system say soft confidence?

02/06/07

When should the system say needs your judgment?

02/06/08

When should the system stop instead of trying to be helpful?

02/06/09

What evidence or explanation would make an output easier to trust?

02/06/10

If the system were uncertain, what should it ask before producing, approving, sending, sharing, delegating, or closing anything?

Session 3 | Relationships And Obligations

Session 3

Relationships And Obligations

01

Recent Thread Trace

03/01/01

Think of one recent thread, message, meeting, request, customer issue, or follow-up that stayed with you in some way. What arrived?

03/01/02

What kind of person or stakeholder was involved?

03/01/03

What did they need, expect, imply, or ask for?

03/01/04

What did you have to hold in your head after that interaction?

03/01/05

What could not proceed without you?

03/01/06

What stayed open afterward?

03/01/07

When it did not close cleanly, who or what brought it back into view?

03/01/08

What parts of this example are safe to treat as a pattern, and what parts should stay role-bound, off-limits, or held for review?

03/01/09

If the system saw a similar thread later, what should it notice before trying to help?

02

Stakeholder Categories

03/02/01

In that thread, what kind of stakeholder was involved?

03/02/02

Are there other kinds of stakeholders who reliably create similar obligations?

03/02/03

Which kinds of stakeholders most often require your personal attention?

03/02/04

Which kinds can usually be handled through delegation, preparation, or monitoring?

03/02/05

Which kinds tend to create follow-ups or open loops?

03/02/06

Which kinds require different communication tone or framing?

03/02/07

Which kinds are clearly current-role-specific?

03/02/08

Which kinds reflect relationship handling you carry across roles?

03/02/09

Where should the system ask before classifying stakeholder knowledge as portable or role-bound?

03

Relationship Sensitivity

03/03/01

Think of a recent situation where the relationship affected how something had to be said. What was happening?

03/03/02

What made that stakeholder, audience, or category sensitive?

03/03/03

What would have been too blunt?

03/03/04

What would have been too vague?

03/03/05

What would have created unnecessary concern, expectation, or exposure?

03/03/06

Did the final judgment depend on the relationship itself, rather than just the content being complete?

03/03/07

Where do you deliberately use direct language?

03/03/08

Where do you deliberately soften, qualify, or defer?

03/03/09

What should the system check before drafting or recommending language for a sensitive relationship?

04

Obligation Sources

03/04/01

Think of a recent case where an obligation was created. What happened?

03/04/02

Was the obligation explicit, implied, or inferred?

03/04/03

Who expected the next move?

03/04/04

What made it yours, if anything did?

03/04/05

What would count as a response?

03/04/06

What would count as completion?

03/04/07

What would happen if it disappeared from view?

03/04/08

Did the obligation create sub-asks or dependencies?

03/04/09

What should the system track, surface, or ask before treating the obligation as handled?

05

Authority and Escalation

03/05/01

Think of one recent situation where someone else had to approve, validate, block, or review something before it could proceed. What was happening?

03/05/02

What authority did that person or group have?

03/05/03

What could you decide yourself?

03/05/04

What could you prepare but not approve?

03/05/05

What required technical, commercial, legal, security, policy, or executive review?

03/05/06

Was the blocker missing information, missing authority, or a judgment boundary tied to role, relationship, or context?

03/05/07

When should the system escalate rather than proceed?

03/05/08

When should the system mark something as waiting on authority?

03/05/09

If the system saw a similar situation later, what should it ask before moving anything forward?

06

Portable vs Role-Bound Relationship Knowledge

03/06/01

What relationship patterns follow you across roles?

03/06/02

What do people tend to rely on you for in relationships, regardless of company?

03/06/03

What stakeholder-handling standards are part of how you operate?

03/06/04

What current relationship knowledge is clearly employer-bound?

03/06/05

What should never become portable?

03/06/06

What could become a portable principle if abstracted properly?

03/06/07

Where is the overlap between your personal relationship judgment and your current role?

03/06/08

Where should the system ask before classifying relationship knowledge?

03/06/09

If the system learned a relationship pattern from your current role, what should it do before reusing that pattern elsewhere?

Session 4 | Workflow Rules And Review Gates

Session 4

Workflow Rules And Review Gates

01

First Workflow Fit

04/01/01

Think of a recent work pattern, day, week, thread, meeting, or open loop where a first workflow could have reduced load. What was happening?

04/01/02

Which pressure should the first workflow reduce?

04/01/03

Should the first useful surface answer what needs judgment today, what loops are open, what meetings need preparation, what drafts need review, what follow-ups were created, or what risks need checking?

04/01/04

What would make that first surface immediately useful?

04/01/05

What would make it feel like another system to manage?

04/01/06

What would need to be visible at a glance?

04/01/07

What should stay hidden unless you ask for detail?

04/01/08

What would make you trust that the system had ranked the work correctly?

04/01/09

What would make you reject the surface immediately?

02

Action Permission Ladder

04/02/01

What is the system always allowed to show you?

04/02/02

What is it allowed to prepare or summarize for you?

04/02/03

What is it allowed to draft for review?

04/02/04

What is it allowed to suggest but not do?

04/02/05

What is it allowed to mark as waiting, blocked, delegated, or ready for review?

04/02/06

What is it allowed to remind you about?

04/02/07

What should require a confirmation button every time?

04/02/08

What should require your judgment even if the system is highly confident?

04/02/09

What should the system never do without explicit approval?

04/02/10

Where should the system stop and ask rather than proceed?

03

Review Gates

04/03/01

Think of a recent case where something should have been held for review. What was happening?

04/03/02

What made it look ready?

04/03/03

What still made it unsafe to proceed without review?

04/03/04

Was the missing gate your judgment, someone else’s authority, relationship sensitivity, policy, evidence, context, or something else?

04/03/05

What signal should have forced a hold?

04/03/06

What signal would have allowed it to move forward?

04/03/07

What should the system say when it is not confident enough?

04/03/08

What evidence would you need to see before trusting the system’s recommendation?

04/03/09

When should the system refuse to produce, approve, send, share, delegate, or close anything?

04/03/10

If the system saw this pattern later, what review gate should it apply by default?

04

UID and Open-Loop Handling

04/04/01

Think of a recent thread, commitment, follow-up, or dependency that needed to stay visible. When did it become an open loop?

04/04/02

What was the actual open loop?

04/04/03

Were there sub-asks or dependent items inside it?

04/04/04

What would make the loop waiting on someone else?

04/04/05

What would make it delegated?

04/04/06

What would make it blocked?

04/04/07

What would make it ready for your review?

04/04/08

What would make it ready to close?

04/04/09

What should prevent it from closing?

04/04/10

When should the system ask whether the loop can be closed?

04/04/11

What evidence should remain attached so you can understand why the loop exists?

05

Communication Routing and Draft Behavior

04/05/01

Think of a recent communication pattern where a useful system could have helped. What was happening?

04/05/02

Should the system have drafted a reply, summarized the issue, suggested an acknowledgment, held the response, escalated the issue, or stayed silent?

04/05/03

What would make a draft useful but not ready to send?

04/05/04

What would make an acknowledgment enough?

04/05/05

What would require your personal framing?

04/05/06

What would require relationship-sensitive language?

04/05/07

What would require employer, legal, commercial, security, or policy review?

04/05/08

What should the system never imply in drafted language?

04/05/09

What should the system ask before creating a draft in your voice?

04/05/10

If the system were uncertain, what should it prepare instead of drafting?

06

Delegation, Reminders, and Quiet Follow-Up

04/06/01

Think of a recent delegated, deferred, or waiting item where a reminder could have helped. What was happening?

04/06/02

What reminder would have been genuinely useful?

04/06/03

When should the system offer a quiet reminder?

04/06/04

When should it avoid reminding you?

04/06/05

What wording would feel respectful rather than patronizing?

04/06/06

When should a delegated item leave your main view?

04/06/07

When should a delegated item remain visible?

04/06/08

When should a transferred item disappear entirely?

04/06/09

When should the system ask whether you want a reminder?

04/06/10

What kinds of follow-up should be grouped rather than shown individually?

04/06/11

What would make follow-up support feel intelligent rather than noisy?

Session 5 | First Operating Surface Trials

Session 5

First Operating Surface Trials

01

Input Choice

05/01/01

Which input is useful enough to test the system without creating unnecessary exposure?

05/01/02

Should this trial use synthetic, redacted, pseudonymized, or described-from-memory material?

05/01/03

What parts of the input are off-limits?

05/01/04

What must remain role-bound?

05/01/05

What can become a reusable pattern if abstracted?

05/01/06

What should be deleted after the trial?

05/01/07

What would make this input safe enough to use for calibration?

02

Surface Ranking

05/02/01

Did the system surface the right item first?

05/02/02

Did anything important appear too low?

05/02/03

Did anything noisy appear too high?

05/02/04

Did the surface protect judgment before attention?

05/02/05

Did the system correctly distinguish important from merely urgent?

05/02/06

Did the ranking reflect your real responsibility?

05/02/07

Did anything appear that should have been hidden?

05/02/08

Did anything important disappear?

05/02/09

What would you move, remove, rename, or hold for review?

03

UID and Open-Loop Interpretation

05/03/01

Did the system identify the right open loops?

05/03/02

Did it split anything that should have stayed together?

05/03/03

Did it combine anything that should have been separate?

05/03/04

Did it recognize sub-asks or dependencies correctly?

05/03/05

Did it correctly identify what was waiting, delegated, blocked, ready for review, or ready to close?

05/03/06

Did it preserve the reason each loop existed?

05/03/07

Did it attach enough evidence to explain why the loop was there?

05/03/08

Did it create any loop that should not exist?

05/03/09

What would have disappeared from your head if this view had existed at the time?

04

Review Gates and Action Permissions

05/04/01

Did the system correctly identify what needed your judgment?

05/04/02

Did it suggest anything it should not have suggested?

05/04/03

Did it hold anything that could have moved?

05/04/04

Did it move anything that should have been held?

05/04/05

Were the review gates clear and appropriate?

05/04/06

Were action suggestions framed at the right authority level?

05/04/07

Did any suggested action feel like overreach?

05/04/08

What should require confirmation every time?

05/04/09

What should the system ask before taking the next step?

05/04/10

What should it refuse to do in this kind of situation?

05

Communication and Draft Behavior

05/05/01

Did any suggested language sound like you?

05/05/02

Did any suggested language sound wrong, generic, too strong, too soft, or too exposed?

05/05/03

Did the system identify when acknowledgment was enough?

05/05/04

Did it identify when a full response should be held?

05/05/05

Did it respect relationship sensitivity?

05/05/06

Did it avoid implying commitments that should not be made?

05/05/07

Did it use the right level of certainty?

05/05/08

What would you approve, edit, reject, or hold?

05/05/09

What should the system learn from your correction?

06

Evidence and Explanation

05/06/01

Was the explanation sufficient?

05/06/02

Was the evidence visible enough?

05/06/03

Was too much evidence exposed?

05/06/04

Did the why this is here reasoning help?

05/06/05

Did the system cite the right source pattern?

05/06/06

Did it make assumptions without showing enough basis?

05/06/07

Did the explanation create confidence or extra work?

05/06/08

What would make the recommendation easier to trust?

05/06/09

What should stay hidden unless you ask for detail?

07

Client Experience and Load

05/07/01

Did this feel useful or heavy?

05/07/02

Did it reduce the need to keep loops in your head?

05/07/03

Did it feel like it was built around you?

05/07/04

Did anything feel patronizing, noisy, or managerial?

05/07/05

Did the interface ask for too much from you?

05/07/06

What would make this worth using tomorrow?

05/07/07

What would make you stop using it?

05/07/08

What should be changed before testing a second input?

05/07/09

What should be confirmed before any real material is used more broadly?

//

TREVOR GILCHRIST

323.‌712.‌1772

323.712.1772

© 2026 Trevor Gilchrist. All rights reserved.

© 2026 Trevor Gilchrist. All rights reserved.

//

TREVOR GILCHRIST

323.‌712.‌1772

© 2026 Trevor Gilchrist. All rights reserved.