Core Concepts | Interloom

Interloom’s domain model is built around a small set of entities that compose into rich workflows. This page covers every core entity, how they relate, and the key patterns that tie them together.

The Environment Tree

Every entity in Interloom occupies a unique position in a containment hierarchy rooted at the Space. This hierarchy — the environment tree — determines where things live, how breadcrumbs render, and what context is available when working on a case.

Organization
└── Space: Claims Operations
    ├── Procedure: Standard Claims Process
    │   ├── ProcedureStage: Intake Review
    │   ├── ProcedureStage: Investigation
    │   └── ProcedureStage: Settlement
    ├── Case: Auto Claim #5179
    │   ├── Stage: Intake Review [completed]
    │   ├── Stage: Investigation [in_progress]
    │   ├── File: Police Report.pdf
    │   ├── File: Repair Estimate.pdf
    │   ├── Note: Initial Assessment
    │   ├── Subtask: Fraud Screening [completed]
    │   └── Subtask: Bodily Injury Evaluation
    ├── Case: Homeowner Claim #7713
    │   ├── Subtask: Emergency Water Extraction [completed]
    │   └── Subtask: Mold Assessment
    └── Note: Q1 Planning

Each entity resolves to a unique path from root to leaf — this is what the breadcrumb displays in the UI. Subtasks can nest arbitrarily deep.

Organization

The top-level business account. An organization owns one or more spaces and provides the tenancy boundary for billing, configuration, and identity.

Space

A workspace container where cases, procedures, users, and agents operate together. Spaces provide isolation between organizational units and membership-based access control.

Spaces can represent departments, projects, client engagements, or any logical grouping. Every user also has a private space — created automatically, with no other human members. AI agents can still be members of a private space.

Spaces can be configured with automation:

Auto-apply procedure — automatically applies a procedure to every new case in the space
Auto-assign — automatically assigns new cases to a specific user or agent

Membership

Users are added to a space as members. Membership determines which spaces (and their cases, files, and notes) a user can access.

Case

The primary unit of work. A case is a top-level task (no parent) that represents a discrete issue, request, or project — an insurance claim, a support ticket, an onboarding request, a compliance review.

Status

Cases track their lifecycle through a single status field:

Status	Meaning
`open`	Case exists, ready for work
`started`	Work is underway
`completed`	Work is done
`blocked`	Halted — needs intervention
`cancelled`	Terminated — no longer needed

open ──→ started ──→ completed
  │         │
  │         └──→ blocked ──→ started (unblocked)
  │
  └──→ cancelled

When a case has stages, the case status is derived from the stage statuses — the case becomes started when the first stage begins, blocked when the current stage is blocked, and completed when all stages are terminal.

Additional Case Properties

Assignee — the user or agent responsible for the case
Due date — an optional deadline
Summary — an automatically generated summary of the case’s objective, progress, and outcomes (updated as work progresses)
Tags — labels for categorization, filtering, and search

Subtasks

A subtask is a task nested under a parent case (or another subtask). Subtasks have their own lifecycle, thread, and assignee. They can follow their own procedures and nest arbitrarily deep.

Subtasks enable parallel work within a case — while stages define the sequential flow, subtasks handle work that can be delegated and run independently. When a subtask completes, its status can inform the parent case’s progress.

Precedent-Based Planning

When creating a plan for a new case, agents can reference similar completed cases to inform their approach. Interloom uses semantic embeddings to find contextually similar past cases and their subtask structures, giving agents a starting point rather than planning from scratch. A plan from a similar case can be applied to the current case, automatically creating matching subtasks.

Stage

A sequential step within a case’s execution plan. When a procedure is applied to a case, it creates an ordered list of stages that define what work needs to happen and in what order.

Each stage has:

Title — a clear, action-oriented name (e.g., “Review incoming documents”)
Instructions — guidance on what to do and what “done” looks like
Assignee — the human or agent responsible for this step

Stage Lifecycle

Status	Meaning
`pending`	Not yet started — waiting for earlier stages to complete
`in_progress`	Currently being worked on
`waiting`	Paused — waiting for subtask results or external input
`completed`	Finished successfully
`blocked`	Halted — needs intervention
`skipped`	Intentionally bypassed

At most one stage per case is in_progress, waiting, or blocked at a time. When a stage completes, the next pending stage activates automatically.

Stages start execution on the first message in the case thread. The stage assignee (if an agent) is automatically invoked to begin working on the stage instructions.

Stage Execution

When an agent completes a stage, it signals <<COMPLETE>> and the platform automatically:

Marks the current stage as completed
Checks if the case has unconcluded subtasks — if so, the stage enters waiting until they finish
Advances to the next pending stage and invokes its assignee

If an agent signals <<BLOCKED>>, the stage is blocked and waits for human intervention. When a human resolves the blocker (by posting a message or manually resuming), the agent is reinvoked to reassess progress.

Stage Controls

Users can manually control stages from the UI:

Begin — start a pending, waiting, blocked, or skipped stage
Complete — mark a stage as done and advance to the next
Skip — bypass a stage and advance to the next
Block — halt a stage for manual intervention

This gives humans full override capability over the automated stage flow.

Procedure

A reusable workflow template that defines a sequence of stages for handling a type of case. Procedures belong to a space and contain ordered procedure stages (templates).

When a procedure is applied to a case:

Any existing pending stages on the case are removed
New runtime stages are created from the procedure’s stage templates
Stages that are already in progress or completed are preserved

Procedures encode best practices — a “Standard Claims Process” might define stages for intake review, investigation, evaluation, and settlement. Each procedure stage specifies a title, instructions, and an optional assignee.

Procedures can be set to auto-apply on a space, so every new case in that space automatically gets the procedure’s stages.

Procedure Stage

A template step within a procedure. Defines position, title, instructions, and an optional assignee — but carries no execution state itself. When the procedure is applied to a case, each procedure stage produces a runtime Stage instance.

User and Agent

All participants in Interloom are users. Users come in two types:

Human users — team members who log in, review work, make decisions, and handle exceptions.

Agents — AI users configured with behavioral instructions, a model, and tool access. Agents can be assigned to cases and stages, post messages, create notes, manage files, and invoke tools — all within the same thread as human collaborators.

Agent Configuration

Job Descriptio — the agent’s role, expertise, how it uses tools, and what it should or should not do
Model — which AI model powers the agent
Tools — which platform capabilities the agent can use. Every new agent starts with a read-only baseline (read notes and files, view a task and its thread, use skills); additional tools are granted individually per agent

Tools

Tools are capabilities that agents use to interact with the platform and external systems:

Category	Tools
Task management	Create tasks, update tasks, set status, view tasks
Notes	Create, read, edit, append to notes
Files	Read files, search files
Discovery	List spaces, list users, find similar tasks, search/manage tags
Procedures	Create/edit procedures, manage stages, apply procedures
Agents	Create, update, view agents and their tools
Code execution	Run Python code in a sandboxed environment, execute predefined scripts
Email	Create and update email drafts
Scheduling	Schedule, view, and cancel messages to post later
Custom Tools	Salesforce queries, SharePoint search, Custom API calls etc.

Tools are granted to agents individually — each agent only has access to the tools it needs for its role.

Custom Tools

Agents — and the people configuring them — can define custom tools: reusable capabilities that wrap an external API or a piece of logic as a typed tool any agent can call. Each custom tool has:

A name and a description telling agents when to use it
A typed input schema (JSON Schema) defining its arguments
Optional secrets exposed to it at runtime, for authenticating to external services

Under the hood, a custom tool runs a script that can call out to HTTP or GraphQL APIs and read only the secrets it was granted — so you can wrap any API as a typed tool without shipping platform code. Custom tools are organization-scoped and owned by their creator; once created, they’re granted to agents individually, like any built-in tool.

Navgate to the Forge to configure Custom Tools and Secrets.

Code Execution

Agents can write and execute Python code in a sandboxed Jupyter environment. This enables:

Data analysis and transformation (CSV, Excel, JSON)
Document generation and formatting
Calculations, comparisons, and validation logic
Creating structured outputs as notes

Files and notes from the case are automatically available to the code environment.

External Integrations

Agents can connect to external systems through configured integrations:

Salesforce — Query records with SOQL, create and update objects
SharePoint — Search across sites and OneDrive for documents
Custom APIs — Query configured GraphQL endpoints, or define custom tools to reach other HTTP services, with configurable authentication

Integrations authenticate using secrets stored securely in Interloom (see Secrets below).

Native Agents

Interloom ships with a built-in assistant:

Odin — the primary assistant, specializing in procedure design, agent configuration, task planning, and platform guidance. Odin also powers Assistant Chat, and can search the web for up-to-date information when a workflow needs it

Agent Reasoning

Agents reason through complex requests before acting. A thinking step shows how the agent breaks down the problem, weighs approaches, and chooses its tools — making its logic easy to follow and course-correct mid-task. Agents reliably handle multi-step work: chaining several tool calls in sequence and stopping cleanly once the task is resolved.

Thread

A chronological sequence of events attached to a case. Threads are the audit trail and communication backbone of Interloom.

Each case has one thread that captures everything: messages from humans and agents, status changes, stage transitions, tool calls, file attachments, and subtask summaries.

Threads can also exist standalone — outside any case — functioning as a an assistant conversation.

Thread Events

Events in a thread include:

Type	Description
Message	A comment or response from a human or agent
File	A document attached to the thread
Task update	A change to the case’s properties
Stage activity	A stage status change (started, completed, blocked, etc.)
Procedure activity	A procedure being applied or modified on the case
Agent invocation	An agent being invoked to work on the case
Agent activity	An agent performing work (tool calls, processing)
Note	A note created or referenced in the thread
Note activity	A note being edited or updated
Outgoing email	An email drafted or sent from the case

File

A document or digital asset attached to a case thread or space. Files can be documents, images, spreadsheets, PDFs, or any other content. Files have a name, size, and MIME type.

Files uploaded to Interloom are automatically indexed in the Document Library, making them searchable across the platform using semantic search. Agents can use the document library to find relevant information across all files in accessible spaces.

Note

A textual document for capturing detailed information, analysis, or working notes. Notes have a title and body (markdown), can have files attached, and belong to either a space or a thread (but not both). Notes are also indexed in the document library and searchable by agents.

Email

Interloom supports both incoming and outgoing email:

Incoming email — Each space can have a unique forwarding email address. Emails forwarded to this address are automatically ingested into the space, creating threads with the email content and attachments.

Outgoing email — Emails can be drafted, reviewed, and sent from within Interloom. Agents can create and update email drafts as part of a workflow. Outgoing emails track delivery status (queued → sending → sent or failed).

Tag

Labels for categorizing cases, notes, and files within a space. Tags are short, descriptive keywords that support filtering, search, and organization. Tags can be applied to and removed from objects, and searched across the platform.

Mentions and Notifications

Users and agents can be mentioned in thread messages using the format @Name. Mentioning an agent invokes it — the agent receives the message context and begins working. Mentioning a human user sends them a notification.

Notifications appear in the user’s inbox and track unread status.

Task Summary

Every case can have an automatically generated summary — a concise description of the case’s objective, key milestones, results, and relevant tags. Summaries are generated from the thread content and updated as the case progresses. They help users and agents quickly understand a case without reading the full thread.

Similar Tasks

Interloom can find similar past cases based on semantic similarity. This powers precedent-based planning — when working on a new case, agents can reference how similar cases were handled previously to inform their approach. Similar tasks are ranked by relevance and can include their subtask structure for comparison.

Secrets

Encrypted storage for API keys, credentials, and configuration needed by integrations. Secrets are used by agent tools (Custom Tools, Salesforce, SharePoint, code execution) to authenticate with external systems. They are stored with AEAD encryption and support key rotation.

Secrets are managed from the Secrets section in the sidebar and referenced by name in tool configurations.

Assistant Chat (Private Assistant)

Users can have standalone conversations with Odin outside of any case — the Private Assistant. These chats function as a general-purpose interface for getting help with the platform, designing procedures and agents, or brainstorming before creating a case. They keep their own history (separate from case data), are backed by threads, and can reference platform objects.

The assistant is also available in a sidecar — a panel alongside the main view — so you can ask about the files or people you’re currently looking at without losing context or switching tabs.