Iron Gorilla Developers

Scoped Memory

Configure hierarchical memory, keep recall inside tenant and environment boundaries, and manage context deliberately.

Iron Gorilla memory follows the agent's business hierarchy inside one organization and one environment. An agent can inherit organization, department, and group memory, then combine it with its own memory and allowed user or task context.

Configure memory

Memory is enabled by default. Declare memory when you want to narrow recall, learning, or writes.

Example
import { defineAutonomousAgent } from "@forge/sdk";

export default defineAutonomousAgent({
  identity: {
    name: "Claims Guide",
    scope: "dept/claims",
    authority: "Explain claim status and next steps.",
  },
  memory: {
    enabled: true,
    inheritedReads: true,
    includeUser: true,
    defaultWriteScope: "agent",
    allowedWriteScopes: ["agent", "group"],
    alwaysLearn: true,
    autoRecall: true,
  },
  goal: "Resolve the request using approved tools and current memory.",
  loop: {
    providerId: "anthropic",
    model: "claude-sonnet-4-6",
    tools: [
      { name: "memory_search", ref: { builtin: "memory_search" } },
      { name: "memory_write", ref: { builtin: "memory_write" } },
    ],
    maxTurns: 12,
  },
});

autoRecall injects relevant approved memory into governed model calls. The built-in memory_search and memory_write tools let an autonomous loop decide when to search or propose a write; both remain fenced to the signed scope and runtime policy.

To permit an organization-scoped write, include "org" in allowedWriteScopes; the loop must then request that scope explicitly. The runtime maps it to the agent's current organization and still applies policy, DLP, approval, and environment fences. Keep defaultWriteScope at "agent" or "group" so broad writes are always deliberate.

Understand the boundaries

  • Organization is the tenant boundary. Memory is never recalled across organizations.
  • Environment is the recall boundary. Organization memory in production is distinct from organization memory in test or development.
  • Hierarchy controls inherited recall inside that environment: organization → department → group → agent.
  • User, session, run, and document memory joins only when the request and policy allow it.

There is no cross-organization or cross-environment memory-sharing API. If the same approved fact is needed in more than one environment, maintain a separately reviewed copy in each environment.

Keep recall inside the context window

Automatic recall ranks a bounded result set and injects only the highest-ranked memory that fits the runtime memory budget. Lower-ranked items stay out. The model's remaining context must still hold instructions, conversation history, tool results, and its response, so broad memory does not guarantee broad recall on every turn.

Keep memory concise and current. Review fast-changing operational memory monthly and stable policy memory at least quarterly. Reject stale, contradictory, duplicative, or weakly sourced candidates. Retention rules can expire old items, and semantic consolidation retires near-duplicates today. Broader automatic compaction and optimization are planned for future releases.

Review learned memory

With alwaysLearn enabled, completed work can produce memory candidates; it does not silently turn every transcript into durable shared context. Use the administrative review endpoints to approve, reject, edit, restore, delete, or purge memory and to manage retention rules. Keep organization and department writes rare: they have the widest inherited effect inside their environment.

On this page