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. Organizations also include member capability settings that independently control whether members can create agents and whether members can create spaces.

Organizations have membership roles: owner, manager, and member. These roles govern organization-level administration separately from space membership. An organization has an active owner; ownership can be transferred by the current active owner to another active human member who has completed signup, and the previous owner is demoted to manager.

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 and agents are added to a space as members. Membership determines which spaces and objects they can access, and which humans or agents are eligible for mentions, assignment, and invocation, including triage-triggered invocation. In private spaces, only listed members are eligible. In public spaces, all human users can be mentioned broadly, but agents are not eligible unless explicitly supported through private-space membership workflows. Agents with the space_membership tool can add or remove human users or private agents from private spaces when workflow access needs correction. Public space membership cannot be changed with this tool, and at least one member must remain.

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:

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. Existing tasks can be moved to another space or under another task, converting or reparenting them within the task hierarchy.

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.

Case Ingestion

Case ingestion is the bulk-import path for creating root cases in a target space from a JSONL manifest. It is intended for external systems or one-time bulk imports that need to create many Interloom cases at once; email-native workflows should use space forwarding addresses.

A case ingestion batch belongs to a space and tracks processing status and counters: total manifest entries, processed entries, successful case creations, and failed entries. Batch statuses are pending, processing, completed, and failed. Entry statuses are success, skipped, and failed.

Manifests are validated before a batch is accepted. Invalid manifests return a validation error and do not start ingestion. Failed entries can be reviewed through the case-ingestion error listing API.

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

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 returns a final response with outcome completed, and the platform automatically:

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

If an agent returns a final response with outcome 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:

1. Any existing pending stages on the case are removed
2. New runtime stages are created from the procedure’s stage templates
3. 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. Procedures can be moved between spaces. If a procedure is moved out of a space where it is the auto-applied procedure, that source space’s auto-apply procedure setting is cleared/disabled.

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 profile details, a job description, a model, organization fields, and tool access. Agents can be assigned to cases, subtasks, and stages, post messages, create notes, manage files, and invoke tools — all within the same thread as human collaborators. When an eligible agent is assigned on task creation or reassigned to an unconcluded case or subtask, Interloom invokes the agent to begin work; stage assignees are invoked when their stage becomes active.

Agent Configuration

• Job title — the agent’s role label within the organization
• Manager — the human user who manages the agent for reporting context. When an agent is created without an explicit manager, the requesting user becomes the manager; agents cannot manage other agents.
• Department — an optional department or team assignment
• Job Description — the agent’s role, expertise, how it uses tools, and what it should or should not do
• Model — which AI model powers the agent
• Reasoning effort — an optional setting for supported reasoning models that controls how much reasoning budget the agent uses (for example, low, medium, high, or xhigh where supported). If unset, the model’s default reasoning effort is used; unsupported models do not store a reasoning effort.
• 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:

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 managed by a human user. The creator becomes the initial manager, and management can be transferred to another human user when the tool has no attached secrets. Only the current manager can view/edit the tool script and secrets or execute it through the custom-tool execution helper; custom tools are granted to agents individually, like any built-in tool.

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:

• SharePoint — Search across sites and OneDrive for documents
• Custom APIs and CRM systems — Define custom tools to query external HTTP/GraphQL APIs, including systems such as Salesforce when configured by your organization

Integrations authenticate using secrets stored securely in Interloom.

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 an assistant conversation.

Thread Events

Events in a thread include:

File

A document or digital asset attached to a task thread (including cases and subtasks) or space. Files can be documents, images, spreadsheets, PDFs, or any other content. Files have a name, size, and MIME type. Files can be moved between spaces and tasks: moving a thread/task file to a space detaches it from the thread and places it in the destination space; moving a space-level or thread/task file to a task attaches it to the destination task thread.

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 can be moved between spaces and task/case threads: moving a note to a space detaches it from its thread, while moving it to a task attaches it to that task’s thread. 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, searched across the platform, and deleted when no longer needed.

Mentions and Notifications

Eligible active users and agents can be mentioned in thread messages using the format @Name. Eligibility is determined by the case’s space membership rules and active organization membership; mentioning an eligible active agent invokes it, while mentioning an eligible active human user sends them a notification. Deactivated users or agents, whose organization membership has been archived, are excluded from active listing, mention, assignment, and invocation surfaces, but may still appear in historical contexts such as past thread messages or assignments.

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.