A hierarchical agency spawns a specialist

The script builds a hierarchical agency like examples/emergent-hierarchical-spawning.mjs, with one specialist allowed, and gives it the sandbox-security brief from examples/single-agent-briefing.mjs. The output is from one run against the OpenAI API. Both examples are in framerslab/agentos/examples.

adapted from examples/emergent-hierarchical-spawning.mjs

JavaScript

import { agency } from '@framers/agentos';

const team = agency({
  provider: 'openai',
  model: 'gpt-4o',
  strategy: 'hierarchical',
  instructions:
    'Coordinate a research team. If the task needs a ' +
    'capability your roster does not cover, call ' +
    'spawn_specialist to mint one.',
  agents: {
    researcher: { instructions: 'Find authoritative sources.' },
    writer:     { instructions: 'Produce concise prose.' },
  },
  emergent: {
    enabled: true,
    judge:   true,
    planner: { maxSpecialists: 1, requireJustification: true, maxJudgeCalls: 3 },
  },
  on: {
    emergentForge: (e) => console.log(
      `[FORGE] spawned "${e.agentName}" approved=${e.approved}`
    ),
  },
});

const result = await team.generate(
  'Write a 2-paragraph briefing on agentic-AI ' +
  'sandbox security risks. Include a security-' +
  'audit perspective on node:vm vs container ' +
  'isolation. The team has no security auditor; ' +
  'spawn one if needed.',
);

console.log(result.text);

output of one run (OpenAI API)

● Captured run

[FORGE] spawned "security_auditor" approved=true

// emergentForge fires after EmergentAgentJudge approves the spec; the manager can call delegate_to_security_auditor from its next turn

Final answer (gpt-4o)

Agentic AI systems operating in sandbox environments present unique security challenges, particularly when considering the isolation methods used to contain these systems. Node:vm (Virtual Machines) provide robust isolation as each VM operates with its own OS and resources, offering strong separation from other environments on the same host. This level of isolation helps to contain the potential impact of any security breach within the AI agent itself. However, VMs can be resource-intensive and potentially slower, as they require more overhead to emulate physical hardware, which might influence performance for high-demand AI tasks. Conversely, container-based isolation, such as Docker, offers a more lightweight and flexible approach as containers share the host kernel while isolating the application at the process level. This can be advantageous for deploying numerous, smaller agentic AI instances. However, from a security-audit perspective, containers can be more vulnerable to kernel-level attacks since they share the same underlying OS. The shared kernel can pose risks if one AI agent exploits a vulnerability to affect others. Therefore, when managing agentic AI in sandbox environments, it is crucial to balance the isolation strength of VMs with the efficiency and scalability of containers, while continuously monitoring and patching both systems to mitigate emerging security risks.

Agent calls (2)

→ researcher: "Research security risks associated with agentic AI in sandbox environments..."

→ writer: "Based on the research summary, produce a two-paragraph briefing for a CTO..."

tokens: 4,272

The team starts with researcher + writer. The prompt asks for a security audit, which neither covers. The manager calls spawn_specialist, EmergentAgentJudge approves the spec, and security_auditor joins the roster, which gives the manager a delegate_to_security_auditor tool. The agent-call list shows that in this run the manager delegated to researcher and writer only. The final answer above is what GPT-4o returned in that run. Its first paragraph misdescribes node:vm, which runs code in a V8 context inside the Node.js process; Node's documentation says it is not a security mechanism.