Loom

Built for real Salesforce runtime constraints

One runtime that holds the whole AI system together.

Loom is a Salesforce-native runtime for AI agents. It brings together prompts, tools, context, channels, memory, and governance so the system behaves like a real product runtime, not just a model call with extra code around it.

Start BuildingView the GitHub repository

Salesforce-nativeGoverned by designBuilt for production

Core Runtime Salesforce Native Governed by Design Public Docs

Public Docs Scope

These docs focus on the core runtime in force-app. The repository also contains addon packages and internal implementation documents, but those internals are intentionally not described in detail here.

Why “Loom”

The name is deliberate. A loom turns separate threads into one structured fabric. That is exactly the job this runtime is doing inside Salesforce. It brings together prompts, tools, context, channels, memory, and governance so they work as one system instead of a pile of disconnected features.

The point is not to glorify the model call. The point is to make the full runtime hold together in production.

Why This Exists

Many Salesforce AI projects start as one prompt, one model call, and one UI surface. That works for early demos, but it breaks down when you need:

• multiple entry points such as chat, email, APIs, and automation
• durable conversation or thread continuity
• governed tool execution and human review
• platform-safe async behavior under Salesforce transaction limits
• clear auditability for support, compliance, and operational debugging

Loom exists to solve that larger problem. It gives you an operating model, not just an LLM integration.

What Makes It Different

The platform is opinionated in a useful way. It separates concerns that many first-generation AI implementations blur together, which makes the runtime easier to operate, extend, and trust.

Runtime Strategy

The framework asks what kind of work this is. Conversational runtimes handle ongoing interaction. Direct runtimes handle bounded work such as classification, enrichment, and controlled automation.

Channel-Aware Delivery

Runtime strategy and interaction channel stay separate, so the same framework can work across chat, email, API, and provider-backed messaging without collapsing into brittle channel-specific agent variants.

Governed by Design

Trust layers, approval controls, user-mode access, and durable audit records are part of the runtime itself, not post-hoc process wrapped around a prompt.

What It Models

The fastest way to understand the framework is to understand the boundaries it models as separate things.

Agent Definition

AIAgentDefinition__c describes what an agent is: prompts, model configuration, runtime style, tools, trust controls, and behavior settings.

Execution

AgentExecution__c is a unit of runtime work. It tracks lifecycle state, resolved strategy, channel, and turn coordination.

Session

InteractionSession__c is the continuity anchor for a conversation, thread, or longer-lived interaction.

Message

InteractionMessage__c captures transport-level inbound and outbound messages.

Execution Step

ExecutionStep__c is the detailed audit trail of what the runtime actually did while handling a request.

That separation is one of the framework’s biggest strengths. A conversation is not the same thing as a runtime work item. A transport message is not the same thing as an execution step. Once those boundaries are clear, the system becomes much easier to reason about.

The Mental Model

The right mental model is simple:

a request enters through an entry surface, the system resolves routing and continuity, starts or resumes execution, lets runtime strategy and interaction channel shape behavior, runs the LLM and tool loop, and then writes the outcome back into durable records.

That is enough for the homepage. If you want the system walkthrough, service map, and diagrams, go next to Runtime Model and Architecture.

What You Can Build

This is where the framework should feel less abstract and more like a product foundation. The same runtime can support user-facing assistants, bounded AI workflow steps, and shared internal AI platforms.

Service

Build case support assistants that can inspect context, draft responses, suggest next actions, and update records with confirmation or approval controls.

This is one of the strongest first product shapes because the value is visible, the human stays in the loop, and the runtime trace is easy to inspect in production.

Sales

Build seller copilots that help with account research, opportunity inspection, meeting prep, activity capture, and guided follow-up workflows.

This is the right shape when you want a copilot that feels embedded in the CRM, not bolted on next to it.

Automation

Build direct runtimes that classify records, enrich data, summarize activity, route work, or run bounded AI tasks from Flow or API triggers.

This is a strong fit when the business need is not “give me a chatbot,” but “add a reliable AI step to a governed workflow.”

Platform

Build an internal AI foundation where multiple teams can configure agents, add capabilities, plug in new providers, and reuse the same runtime, routing, and governance model.

This is where the story becomes most powerful: one governed runtime, many business-facing AI experiences.

Core Capabilities

Conversational Agents

Build assistants that preserve continuity across turns, sessions, and channel-aware reply flows.

Direct Agents

Run bounded work units for classification, enrichment, automation, routing, or structured decision support.

Metadata-Driven Routing

Use metadata to decide which agent owns a request, how a channel behaves, and how delivery should work.

Trust Layers

Combine masking, prompt safety, tool gating, and approval flows as runtime concerns rather than post-hoc guardrails.

Observability

Inspect executions, steps, messages, sessions, token usage, and outcomes with durable system records.

Extensibility

Add actions, context providers, LLM adapters, and memory strategies without throwing away the core runtime model.

Who This Is For

Loom is especially useful for teams that need more than a single chatbot or a one-off model integration.

It is a strong fit when you are building:

• Salesforce-native assistants that need durable continuity
• governed business automations that must respect user permissions and approval rules
• channel-aware agent experiences across chat, email, API, or provider-backed messaging
• extensible agent platforms where new tools, providers, and context sources will be added over time
• production systems where observability, auditability, and operational safety matter as much as the model itself

It is a weaker fit if all you need is a single prompt, a single response, and no durable runtime or governance layer.

Reader Paths

1. Start building

   Deploy the core package, connect a provider, create an agent, and validate your first runtime path.

2. Understand the system

   Read the Runtime Model and Architecture pages to form the right mental model before diving into implementation details.

3. Configure production behavior

   Use Configuration, Security, and Standard Actions to decide how agents should behave in a governed environment.

4. Extend the framework

   Use the Developer Guide when configuration is no longer enough and you need custom actions, context providers, or provider adapters.

Go Next

Getting Started

Runtime Model

Configuration

Use Cases