sous | The Execution Layer for AI Agents

How It Works

CORE FEATURES

No Build Step

Publish functions instantly as UTF-8 text and JSON manifests. No Docker builds, no CI wait times, just code to execution.

Capability Security

Strict allowlists for network egress and side effects. The runtime blocks filesystem access and process spawning by default.

Unified Fabric

A single execution engine for HTTP calls, recurring schedules, and Cadence Activities. One pool, multiple triggers.

Immutable Aliasing

Every publish creates an immutable version. Use aliases to promote versions between environments with zero downtime.

Runtime Parity

The CLI uses the exact same cs-js runtime as the server. If it works on your machine, it works in the cluster.

Deep Observability

Automatic persistence of activation records and user logs. Query results and audit trails via the control plane API.

Agent Workflow

# 1. Initialize (creates function.js + manifest.json)
$ cs fn init reconcile --runtime cs-js

# 2. Test locally (runs in the local sandbox)
$ cs fn test reconcile --event ./event.json

# 3. Upload code as a Draft (This sends function.js to cloud)
$ cs fn draft upload reconcile --path .
> Draft created: drf_01J2...

# 4. Publish immutable version from Draft
$ cs fn publish reconcile --draft drf_01J2... --memory-mb 128

# 5. Point 'prod' alias to version 42
$ cs fn alias set reconcile prod --version 42

✔ Success. Function promoted to production._

// Agent-generated automation: reconcile.js
export default async function(event, context) {
  // 1. Destructure input from the agent task
  const { orderId, expectedTotal } = event;

  // 2. Execute side-effect (requires capability)
  const res = await fetch(`https://api.stripe.com/v1/orders/${orderId}`);
  const order = await res.json();

  // 3. Pure logic: compare and reconcile
  const status = order.amount === expectedTotal ? 'MATCH' : 'MISMATCH';

  // 4. Return serializable result
  return {
    orderId,
    reconciled: true,
    status,
    timestamp: new Date().toISOString()
  };
}

{
  "name": "reconcile",
  "runtime": "cs-js",
  "privileges": {
    "capabilities": [
      "network:egress:api.stripe.com",
      "network:egress:internal-db.local"
    ],
    "roles": {
      "invoke-http": ["admin", "worker"]
    }
  },
  "limits": {
    "timeout_ms": 3000,
    "memory_mb": 64
  }
}

Benchmark & Density

sous balances aggressive isolation with low-overhead execution. Designed to run thousands of short-lived functions with predictable latency.

Cold Start vs Complexity

RUNTIME

sous (cs-js) maintains sub-50ms cold starts by avoiding heavy container overhead, using lightweight process isolation.

Memory Footprint per Function

DENSITY

< 50ms

Median Execution overhead

1000+

Concurrent Tasks / Node

Technical FAQ

What is the "No Build Step" promise?

Unlike traditional serverless platforms that require Docker builds or compilation, sous accepts function code as plain UTF-8 text. This allows agents to generate, upload, and execute code in seconds without CI/CD overhead.

How does capability-based security work?

Security is enforced at the runtime level. A function must declare its capabilities (e.g., network egress to a specific domain) in its manifest. By default, the sandbox blocks all filesystem access, process spawning, and private network ranges.

Why use codeQ as a buffer?

codeQ acts as a reliability layer between ingress (HTTP/Schedule) and execution (Invoker Pool). It provides backpressure, allows for independent scaling of pollers and invokers, and ensures that user code failures don't impact the ingress loop.

How does sous latency compare to AWS Lambda?

Total response time for synchronous calls in sous may be higher than AWS Lambda or Google Cloud Functions due to the mandatory decoupling through the codeQ bus for reliability. However, the trade-off is massive efficiency: our memory footprint is 90.6% lower (approx. 12MB vs 128MB minimums), allowing for extreme tenant density and significantly lower infrastructure costs.

Is there parity between local and remote environments?

Yes. The cs CLI uses the exact same cs-js runtime semantics and host APIs as the server. This "Runtime Parity" ensures that if a function passes locally via cs fn test, it will behave identically in the cluster.