What happens
after you go to bed

An agent is a server-side, versioned definition: model, system prompt, toolset, subagent roster. Each business gets its own Coordinator at onboarding; editing the profile updates the same agent in place, producing a new immutable version. Sessions reference the agent by bare id — string shorthand means “latest version” — so a profile edit takes effect on the next night’s run with no re-provisioning.

// one-time, at onboarding
const agent = await client.beta.agents.create({
  name: `Moonlings — ${profile.name}`,
  model: "claude-sonnet-5",
  system: buildCoordinatorSystem(profile),  // the business, baked in
  tools: buildAgentTools([]),               // base toolset + google_search (bash disabled)
  multiagent: { type: "coordinator", agents: [SCOUT_AGENT_ID] },
});

One subtlety that bit us: model choice lives per version. Changing a model constant in code does nothing for existing tenants until every live agent is re-versioned — we keep a migration script for exactly that.

A session is one night’s disposable workspace: the agent runs inside a sandbox with a real filesystem and writes its deliverables to /mnt/session/outputs/. Sessions are cheap and per-run — the durable state lives in memory stores, never in the session. After harvest we archive the session; helpfully, its output files survive archival, so a missed attachment is always recoverable.

Each business owns a persistent memory store, seeded at onboarding with profile.md and grown into six standing files: profile.md, learnings.md, competitors.md, leads.md, suppliers.md, patterns.md. The Coordinator’s first instruction on every task is memory first — build on what you know, then report what changed, which is what an owner actually cares about. Agents are told to correct stale facts in place: small, current files beat long archives.

The same mechanism, mounted read-only, carries the owner’s reference library — uploaded price lists, menus, policies. When the web disagrees with the owner’s documents, the documents win, and no agent can ever edit them.

Connected accounts (Google Business, Google Ads, Instagram/Facebook) authenticate through a per-tenant vault. OAuth tokens live there — not in our database, not in the model’s context. At session time we attach at most one vault id, resolved by a pure function that can only ever return the passed business’s own vault; cross-tenant leakage is structurally impossible, not just policy.

If a connected server rejects its credential mid-run, we detect the auth-failure event during collection and flip the connection to needs reauth — the run still completes on its snapshot data; the owner sees a reconnect banner, never a dead report.

The Coordinator’s definition declares multiagent with one shared Haiku Scout on the roster. At run time it spawns one Scout per independent target — competitor, lead, supplier — each in its own thread of the session, in parallel. Prompt discipline caps the fan-out (“never more than 5 Scouts — cost scales directly with Scout count”).

Threads are also how we price honestly: each thread reports its own model and usage, so a finished run is costed per thread at that model’s rates — Sonnet for the Coordinator’s judgment, Haiku for the Scouts’ volume — instead of a flat worst-case estimate.

Connected-account tools arrive over MCP (Model Context Protocol) servers, but the agent never gets a server’s full surface. Every toolset defaults to everything off, then enables an explicit, hand-verified read-only allowlist — 18 tools for social analytics, similar for Google Business and Ads. Each allowed tool is marked always_allow because there’s no human awake at 3 AM to approve anything.

// per connection
{
  type: "mcp_toolset",
  mcp_server_name: "googlebusiness",
  default_config: { enabled: false },          // deny by default
  configs: readToolAllowlist.map((name) => ({
    name, enabled: true,
    permission_policy: { type: "always_allow" }, // unattended runs never stall
  })),
}

The tools array on an agent update is a full replacement, so every sync re-emits the base toolset and web search — a connect or disconnect can never silently drop the agent’s core capabilities.

Task runs don’t get a chat message — they get a defined outcome: the kickoff plus a written rubric the platform grades the finished work against. Fail the grade, and the agent revises; we cap it at two cycles, because each extra cycle re-runs the whole Coordinator-plus-Scouts fan-out and the third pass was our single most expensive knob for marginal gain.

Collection trusts only terminal grader states (satisfied / max_iterations_reached / failed). A session reports idle transiently — including right after kickoff, before any work — so “idle means done” would harvest empty sessions mid-flight. That trap cost us a debugging night; the fix is encoded in the collector.

Some tools we deliberately keep outside the sandbox. When the agent calls google_search, the session emits a tool-use event and waits; our collector executes the search host-side via Serper and posts the result back. The API key never enters the agent’s environment. Scout calls from subagent threads carry a thread id we echo back so the answer lands in the right thread.

// the agent asked; the host answers
await client.beta.sessions.events.send(sessionId, {
  events: [{
    type: "user.custom_tool_result",
    custom_tool_use_id: use.id,
    content: [{ type: "text", text: serperResults }],
    session_thread_id: use.threadId,   // route back to the Scout that asked
  }],
});