Part 3: Autonomy

Chapter 9: The Autonomous Organization

Workflows, Schedules, Channels, and the Vision of Delegated Operations

10 min read8 sections

The Problem

The previous chapters built up the components: agents that execute tasks (Chapter 2), workflows that orchestrate multi-step processes (Chapter 4), profiles that specialize agent behavior (Chapter 6), swarms and handoffs that coordinate multiple agents (Chapter 7), and permission systems that keep humans in control (Chapter 8). This chapter is about what happens when you combine all of them. The autonomous organization is not a single feature -- it is the emergent property of workflows, schedules, profiles, permissions, and channels working together to run business processes with minimal human intervention.

The vision is specific: a system where a heartbeat schedule fires every morning, an agent evaluates whether any business conditions need attention, hands off findings to specialist agents, those agents produce reports and recommendations, the results are delivered to Slack and Telegram, and the human reviews a summary over coffee. The work happened overnight. The human's role was to design the system, not to operate it.

We are not there yet for every use case. But for a growing number of operational patterns -- daily briefings, competitive monitoring, support ticket triage, financial reporting -- the pieces are in place today. This chapter paints the picture of how those pieces fit together, with working code from the codebase.

The Five Pillars

An autonomous organization in Stagent rests on five pillars. Remove any one and the system degrades -- not catastrophically, but enough to require constant human attention that defeats the purpose.

Pillar 1: Workflows as Business Processes

Workflows encode repeatable processes. Stagent supports six orchestration patterns, each mapping to a different organizational need:

Sequence -- steps execute in order. The assembly line.
Planner-Executor -- a planning step generates a plan, then an executor carries it out. The manager-worker pair.
Checkpoint -- inserts human approval gates between steps. The review board.
Autonomous Loop -- repeats until a stop condition is met. The monitoring agent.
Parallel Research -- fans out concurrent investigations, merges results. The research team.
Multi-Agent Swarm -- multiple profiles collaborate with dynamic handoffs. The cross-functional team.

The workflow engine manages the full lifecycle: step sequencing, context forwarding between steps, profile assignment per step, and parallel execution with concurrency limits.

src/lib/workflows/engine.ts

export async function executeWorkflow(workflowId: string): Promise<void> {
  const [workflow] = await db
    .select()
    .from(workflows)
    .where(eq(workflows.id, workflowId));

  if (!workflow) throw new Error(`Workflow ${workflowId} not found`);

  const definition: WorkflowDefinition = JSON.parse(workflow.definition);
  const state = createInitialState(definition);

  await updateWorkflowState(workflowId, state, "active");

  // Open a learning session to buffer context proposals during execution.
  openLearningSession(workflowId);

  // Loop pattern manages its own lifecycle — delegate fully
  if (definition.pattern === "loop") {
    // ...
  }
}

The workflow blueprint gallery includes both technical and business-function templates: code review pipelines, deploy-and-verify sequences, but also lead research pipelines, content marketing pipelines, customer support triage flows, financial reporting workflows, and daily business briefings. These blueprints are not toys -- they are pre-built processes that encode real operational patterns.

Pillar 2: Schedules as Heartbeats

Schedules turn workflows from on-demand tools into always-on systems. Stagent supports two scheduling modes, and the second one is the key to autonomous operations.

Clock-driven schedules fire on a fixed cadence. Every hour, every day at 9 AM, every Monday at 10 AM. These are the cron jobs of the AI-native world -- reliable, predictable, and sometimes wasteful. A daily report that runs even when there is nothing to report burns tokens for nothing.

Heartbeat schedules solve this. They evaluate a checklist of conditions before deciding whether to act. If no conditions are met, the run is suppressed -- no task is created, no tokens are spent.

src/lib/schedules/heartbeat-prompt.ts

export interface HeartbeatChecklistItem {
  id: string;
  instruction: string;
  priority: "high" | "medium" | "low";
}

export function buildHeartbeatPrompt(
  checklist: HeartbeatChecklistItem[],
  scheduleName: string
): string {
  const checklistLines = checklist
    .map(
      (item, i) =>
        `${i + 1}. [${item.priority.toUpperCase()}] (id: "${item.id}") ${item.instruction}`
    )
    .join("\n");

  return `You are performing a heartbeat check for "${scheduleName}".

Evaluate each checklist item below and determine whether any action is needed.

Checklist

${checklistLines}

Instructions

For each item, evaluate whether the condition described needs attention RIGHT NOW.

If the item's condition is satisfied (something needs attention), mark it as "action_needed"
If everything looks normal, mark it as "ok"
If you cannot evaluate the item (missing data, access issues), mark it as "skipped"`; }

text


The heartbeat pattern is profoundly different from clock-driven scheduling. A clock schedule asks "what time is it?" A heartbeat schedule asks "does anything need my attention?" This is the difference between a night watchman who checks every door on a fixed route and one who responds to alarms. The heartbeat is cheaper (suppressed runs cost nothing), more responsive (it acts when conditions demand it), and generates less noise (no empty reports cluttering the task board).

### Pillar 3: Profiles as Departments

The twenty built-in profiles are not just agent configurations -- they are the departments of the autonomous organization. When combined with workflows and schedules, each profile represents a business function that can operate semi-independently.

Consider a "Morning Operations Check" heartbeat schedule with this checklist:

- Are there any failed tasks from overnight?
- Do any projects have stale tasks older than 7 days?
- Are there pending approval requests in the inbox?
- Have any competitive intelligence alerts triggered?

The heartbeat fires with the Operations Coordinator profile. If it finds stale tasks, it can hand off to the Project Manager profile to triage. If it finds competitive alerts, it can hand off to the Marketing Strategist profile for analysis. Each handoff respects the governance gates from Chapter 7 -- chain depth limits, self-handoff prevention, optional human approval.

This is the departmental model: the Operations Coordinator is the COO, dispatching work to specialists. The Financial Analyst runs quarterly reports. The Content Creator produces the weekly newsletter. The Sales Researcher qualifies new leads. Each profile has its own tool permissions, behavioral instructions, and runtime preferences. Together, they form an organization that operates on a rhythm defined by schedules.

### Pillar 4: Permissions as Policy

The permission system (Chapter 8) becomes organizational policy when applied at scale. Trust tier presets define the baseline -- Read Only for monitoring agents, Git Safe for development agents, Full Auto for autonomous operations agents. Per-profile `canUseToolPolicy` configurations provide fine-grained control.

The budget guardrails add a financial dimension to policy. Each schedule can have a per-firing cost budget. The system-wide spend cap prevents any combination of schedules and handoffs from exceeding a monthly ceiling. When usage crosses 80%, a budget alert notification fires. After 100%, new agent work is blocked.

This layered policy -- tool permissions, budget caps, governance gates -- means you can grant broad autonomy to the system while maintaining hard limits on what it can actually do. The Operations Coordinator can hand off to any specialist, but the chain stops at depth 5. The Financial Analyst can run expensive Claude Code tasks, but the daily budget caps spending. The Content Creator can use all tools, but dangerous Bash commands still require approval.

> [!tip]
> **Budget-Aware Scheduling**
> For heartbeat schedules that fire frequently (every 30 minutes), pair them with tight per-firing budgets and route them to Ollama for the evaluation step. The heartbeat check itself runs locally at zero cost. Only if action is needed does the system spin up a more capable (and more expensive) provider for the actual work. This pattern can reduce monitoring costs by 90% while maintaining the same responsiveness.

### Pillar 5: Channels as Nervous System

Delivery channels connect the autonomous organization to the humans who oversee it. Without channels, governance events live in a web UI that someone has to remember to check. With channels, those events push to Slack, Telegram, or webhook endpoints -- the platforms the team already uses.

The channel adapter interface captures the full spectrum of communication:

<!-- filename: src/lib/channels/types.ts -->
```typescript
export interface ChannelAdapter {
  channelType: string;
  send(message: ChannelMessage, config: Record<string, unknown>): Promise<ChannelDeliveryResult>;
  testConnection(config: Record<string, unknown>): Promise<{ ok: boolean; error?: string }>;

  // Bidirectional support (optional)
  parseInbound?(rawBody: unknown, headers: Record<string, string>): InboundMessage | null;
  verifySignature?(rawBody: string, headers: Record<string, string>, config: Record<string, unknown>): boolean;
  sendReply?(message: ChannelMessage, config: Record<string, unknown>, threadId?: string): Promise<ChannelDeliveryResult>;
}

Outbound channels deliver results: the daily briefing lands in the #operations Slack channel every morning at 9:01. Bidirectional channels go further: a team lead can reply to the briefing with follow-up questions, approve handoffs, or deny permission requests -- all without leaving Slack.

The channel gateway bridges inbound messages to the chat engine, creating conversation bindings that persist across messages. A Slack thread becomes a persistent conversation with the agent, complete with permission handling and context memory. This is not a toy chatbot -- it is the same full-featured agent runtime that powers the web UI, accessed through a different surface.

The Smart Runtime Router

The autonomous organization does not run on a single AI provider. Stagent's five-runtime architecture means different parts of the organization can use different providers based on cost, capability, and privacy requirements.

src/lib/agents/router.ts

export function suggestRuntime(
  title: string,
  description: string | undefined | null,
  profileId: string | undefined | null,
  availableRuntimeIds: AgentRuntimeId[],
  preference: RoutingPreference = "latency",
): RuntimeSuggestion {
  // Layer 1: Manual preference → return default
  // Layer 2: Profile affinity → use profile's preferredRuntime
  // Layer 3: Keyword scoring → match task text against keyword signals
  // Layer 4: Preference tiebreaker → cost/latency/quality scoring
  // Layer 5: Credential filter → only suggest runtimes with valid keys
}

The router scores each available runtime on three dimensions -- cost, latency, and quality -- and selects the best fit based on the user's preference. Ollama scores highest on cost (free, always $0) and lowest on quality (local models, smaller parameter counts). Claude Code scores highest on quality (battle-tested, full tool suite) and lowest on cost (SDK overhead). The router navigates these trade-offs automatically.

In the autonomous organization, this means:

Heartbeat evaluations route to Ollama -- zero cost, acceptable quality for yes/no checklist decisions
Research and analysis routes to Anthropic Direct -- fast, no subprocess overhead, extended thinking for deep reasoning
Code modifications route to Claude Code -- full filesystem access, tool approval flow
Data visualization routes to OpenAI Direct -- server-side code interpreter, image generation

The same workflow can use different runtimes for different steps. A lead research pipeline might use Ollama for initial screening (cheap), Anthropic Direct for deep research (fast), and OpenAI Direct for generating the final report with charts (visual).

Putting It All Together

Here is what a real autonomous operation looks like, end to end.

Setup (one time):

Configure Slack and Telegram delivery channels in Settings
Set a monthly budget cap of $100 with per-provider daily limits
Enable Git Safe permission preset plus Bash(command:npm *) and Bash(command:git *)
Create a heartbeat schedule: "Daily Operations Briefing," weekdays at 8 AM
Add checklist items: failed tasks, stale projects, pending approvals, competitive alerts
Assign the Operations Coordinator profile, route heartbeat evaluation to Ollama

Daily execution (automatic):

8:00 AM -- Scheduler tick finds the due schedule, claims it atomically
8:00 AM -- Heartbeat evaluation runs on Ollama (zero cost): 3 of 4 checklist items are "ok," one is "action_needed"
8:01 AM -- Since action is needed, a task is created with the full evaluation report
8:01 AM -- The Operations Coordinator hands off the competitive alert to the Marketing Strategist
8:01 AM -- Governance validates the handoff (chain depth 0, not self-handoff, profile exists)
8:02 AM -- The Marketing Strategist runs on Anthropic Direct, produces a competitive analysis
8:03 AM -- Results are delivered to the #operations Slack channel
8:05 AM -- The team lead reviews the briefing in Slack, asks a follow-up question
8:06 AM -- The channel gateway routes the question to the chat engine, which responds in-thread

The human did not open Stagent's web UI. They did not approve any permissions (Git Safe preset covered the tools). They did not create any tasks. They reviewed a summary in Slack and asked one question. The system did the rest.

Lessons Learned

Start with One Schedule, Not Ten. The temptation when you see the scheduling system is to create a schedule for everything. Resist this. Start with a single heartbeat schedule -- a morning operations check is ideal. Run it for two weeks. Understand its behavior, its cost profile, its false positive rate. Then add a second. Organizational autonomy is built incrementally, not declared all at once.

Heartbeats Over Clocks. Every clock-driven schedule should be evaluated for conversion to a heartbeat. The question is always: "Does this need to run even when there is nothing to report?" If the answer is no, add a checklist and make it a heartbeat. The cost savings compound fast -- a daily schedule that suppresses 4 out of 5 runs saves 80% of its token spend.

Channels Are Not Optional. An autonomous organization that only communicates through a web UI is not autonomous -- it is a system that requires someone to check a dashboard. Channels transform autonomy from "the system did work that nobody noticed" to "the system did work and told us about it." The difference is the difference between a useful automation and a liability.

The Budget Is the Ultimate Governance Gate. Tool permissions control what agents can do. Budget caps control how much they can do. In an autonomous organization where schedules fire daily and handoffs create cascading tasks, the budget cap is the backstop that prevents a misconfigured heartbeat from running up a four-figure bill over a weekend. Set it before you set anything else.

Design the Organization, Then Step Back. The human's role in an autonomous organization is organizational design, not operations. You choose the profiles, define the workflows, configure the schedules, set the permissions, wire up the channels, and establish the budgets. Then you step back. The system operates within the bounds you designed. Your ongoing role is to review results, refine the design, and handle the edge cases that fall outside the system's competence. This is a fundamentally different relationship with work than managing a task list.

Where This Is Heading

The autonomous organization described in this chapter is not science fiction -- every component is implemented and running in the codebase. But we see three areas where the vision expands.

Cross-workflow learning. Today, each workflow execution starts fresh (aside from learned context). We envision workflows that improve their own checklist items based on past results -- a heartbeat that learned which conditions are almost always "ok" and stops checking them, or one that adds new conditions it discovered during execution.

Dynamic profile selection. Today, schedules are assigned a fixed profile. We envision heartbeat schedules that choose their own specialist profiles based on what they find -- detecting that the issue is financial and routing to the Financial Analyst rather than the generic Operations Coordinator.

Organizational memory. The episodic memory system (Chapter 6) operates at the profile level. We envision an organizational memory that spans profiles -- the Marketing Strategist's competitive insights feeding into the Sales Researcher's lead qualification, the Customer Support Agent's ticket patterns informing the Operations Coordinator's checklist. Shared memory turns a collection of independent agents into an organization with institutional knowledge.

The path from here to there is the same path we have followed throughout this book: build the components, validate them in production, compose them into higher-level patterns, and add governance at every layer. The autonomous organization is not the destination. It is the platform on which the next generation of AI-native business processes will be built.

Try: Create a Schedule

Explore Related Features

workflows profiles schedules

Contents

Reading Settings