Technical film / 01
Inside the AI office
See where information lives, which services do the work, and where the model connects.
Read transcript ↓Rufous / Technical
An office connected.
Every boundary explained.
Follow the information, the decisions, and the safeguards that make the agent office work.
PERSONAL CONTEXT.CONNECTED WORK.
Open demonstration
Try the system. Explore the company design.
This site is open to everyone and uses a separate set of fictional company records. Demo personas and their notes are shared with other reviewers. No company account is required. The security films and identity diagram explain the separate private company deployment; they do not describe a sign-in requirement for this public demo.
Your interactions run real agents and scoped tools against the demo stores. Company records, signing keys and conversations from the private workspace are not connected here.
Loading the architecture…
Architecture illustrationScroll the diagram sideways to explore all components.
Component detail
Select a component
Choose any box in the diagram to inspect its responsibility and boundary. Use the steps to trace a complete flow.
Watch how it connects
Three views under the surface.
Narrated architecture diagrams, with selectable captions and full transcripts.
Technical film / 02
From question to verified answer
Follow a single question through both access checks, source retrieval, and a reviewable result.
Read transcript ↓Technical film / 03
Knowledge, review and coordination
Explore personal and company knowledge, peer review, and scoped assistant handoffs.
Read transcript ↓Implementation / data contracts
What is stored. What is checked. What connects.
The knowledge workspace is connected to the same enforced tool boundary as the assistant. Inspect your knowledge stores →
01 / Authoritative records
Personal store / employee working notes, summaries, journal versioned text records earlier revisions retained separate full-text database Company store / collection shared company + department notes draft → review → published separate full-text database
File metadata includes title, author, revision, status, and update time. Published proposals also record the reviewer. Content digests identify changed records; search databases can be rebuilt from the files.
02 / Scope calculation
caller raw scope: [employee A] agent raw scope: [employee A] allowed overlap: [employee A] supervisor raw: [] allowed overlap: [] company collections: shared company + own department
The browser session and tool grants use separate signing keys. A tool grant lasts 240 seconds. Tools verify the signature and recalculate the scope intersection before accessing data.
03 / Knowledge request contract
Search: collection + query Read: returned record ID Save: title + body + current revision Propose: selected text + collection Human review: proposal ID + current revision submit / approve / return to draft
Private record IDs resolve inside the current principal’s store. Stale revisions are rejected to prevent overwriting newer work. Locks serialize writes per store. Agents have no publication or review operation.
04 / Data and event paths
Source ingestion → person’s source index Knowledge files → scoped knowledge index Signed session → short-lived grant → bounded agent turn → authorized tool → execution receipt → cited answer Signed request → durable recipient → aggregate reply + correlation ID
Private prompts and handoff queries are excluded from shared operational views. A knowledge promotion copies the selected text into a new draft; it does not grant access to the personal store.
Security & data boundaries
Company context stays within controlled infrastructure.
Private access, isolated agent execution, and encrypted state. Trace the security diagram →
01 / Identity before access
Private HTTPS verifies the connected network account against an explicit access policy. Company identities map to one employee, agent and role. Sessions are bound to that account; altered or replayed gateway assertions are rejected.
02 / A network with no default route
The application has its own network namespace. It can reach only fixed mail and private inference gateways. The message broker and agent endpoints stay inside this namespace. A model outage produces an unavailable response; there is no external provider fallback.
03 / Separate execution and data
Each agent turn sees its own session files and read-only application code. Company stores, other session homes and signing keys are outside its filesystem. A trusted tool gateway checks the signed grant and current scope before reading or writing records.
04 / Encryption and recovery
Knowledge, mail, indexes, profiles and durable messaging state live on an encrypted volume with a hardware-sealed unlock key. Backups are encrypted before off-host transfer. Recovery credentials are held separately, and restore checks verify files and indexes.
05 / Private model connection
The model runs on a controlled GPU host, in a container without internet egress. A fixed gateway and encrypted tunnel carry permitted context to that host. The tunnel currently uses a restricted transport hop; its credentials allow only the required forwarding destinations.
06 / Explicit trust and review
Host administrators, the application and the data gateway remain trusted. Company publication requires another eligible employee’s approval. The approved demo reviewer can switch fictional personas; assigned company accounts cannot. MFA policy belongs to the organization’s identity provider and is not asserted by this demo.
Architecture illustrations explain the deployment; they are not live security telemetry. An execution receipt proves that a tool ran, not that every sentence in an answer is correct.