Connected intelligence
How a MainSDK app notices trouble, reacts within limits you declare, learns what normal looks like, looks out for its neighbours and lets an agent operate it, with a person in charge.
At 03:00 someone starts guessing passwords against your sign-in page. Your app sees twenty failures a minute from one network, blocks that network for half an hour, tightens its sign-in limit, raises its posture and tells the other MainSDK apps on the machine, which raise theirs. A minute later CPU on the box climbs; your report worker, the least important app there, pauses its optional jobs until things calm down. In the morning you read one line per reaction saying what fired it, what changed, and that it all rolled back on its own.
That is connected intelligence. It is five layers, each useful alone, all running inside your app, off the request path, and free.
The layers
| Layer | What it does | You write |
|---|---|---|
| Signals | Every part of the app that notices something says so with one typed, signed, short-lived signal: attack.suspected, pressure.high, dependency.degraded, key.rotated, anomaly.detected | Nothing; or signals.emit("app.…") for your own |
| Norms | The app learns what normal looks like for itself, by hour of the week, with plain arithmetic and no model, and emits anomaly.detected when a metric leaves the range | norms: in main.yaml, optional |
| Playbooks | Declared reactions: when a signal arrives, run steps from a closed list (tighten a limit, block a network, turn off a flag, pause optional jobs, raise posture, rotate a key, page someone) | playbooks: in main.yaml, or the three presets |
| Neighbours | Apps on one machine hear each other's signals, and declared peers can ask three things: status, raise posture, shed load | neighbours: in main.yaml |
| Operate surface | Claude Code or any MCP agent can ask the running app how it is, what it saw, what a playbook would do, and ask for a run that a person approves | mainsdk ops mcp, registered by mainsdk init |
An optional advisor (planned for 0.6) lets a model propose one of your declared playbooks with a reason. It is off unless you turn it on, and a person approves what it proposes.
The rules that keep it safe
- Every reaction only tightens, and every reaction ends. A step can lower a limit, add a blocked range or turn a feature off; it can never open anything. It holds for at most 24 hours and rolls back when the condition clears, when errors or latency get worse after it, or when you revert it.
- You decide what runs on its own. A playbook waits for a person's yes unless you write
run: auto. Steps that touch people (read-only mode, signing everyone out, rotating a secret) always wait. No agent, neighbour or model can approve. - Some things are never a reaction: deleting data, moving money, loosening any grant, deploying code, editing
main.yaml, running programs, messaging your users and cross-tenant work. - One guard for every source. A rule, a neighbour's ask, the advisor and an MCP agent all go through the same executor, with ceilings on what can change at once, runs per hour, loops between apps and one tenant's trouble changing the app for every tenant.
- Nothing leaves the machine. Signals between apps travel on user-only sockets. Fleet is where views across machines live.
playbooks:
use: [attack, pressure, key-rotation]
presets:
attack: { limits: [sign-in], posture: high, notify: oncall }
pressure: { flags: [recommendations] }
neighbours:
host: on
listen: [attack.*, pressure.*]
share: [attack.suspected, pressure.high]Shared context, with consent
Apps from one owner on one machine (a study app and its parent dashboard) may also share a small picture of the person using them, such as language, accessibility settings or a finished lesson, but only for a purpose that person agreed to in both apps. The id that links it comes from their sign-in or a random first-party id they can reset, never an advertising or device id. It stays on the machine unless you declare a sink inside your own app, it expires within 90 days, and it is exported and erased with the person. These are connected apps that respect the user, not an ad-tracking SDK (ADR-0071).
Who gets what
| Your app | What you get |
|---|---|
| Several MainSDK apps on one server or desktop | Everything: signals, norms, playbooks, neighbours, shared context and the operate surface |
| One app on a long-lived server or container | Signals, norms, playbooks and the operate surface; neighbours and shared context wait for a second app |
| One serverless app | Norms (from request, error and latency counts kept in the store) and the operate surface during development. There is no machine to share, no long-lived instance to slim and no host bus |
What we left out
- Free-form negotiation or conversation between apps; agent-to-agent calls over A2A arrive later with the platforms work.
- Automatic changes to code, data or configuration.
- Reading what other processes on the machine are doing. The app infers contention from its own delay and CPU share.
Next
Was this page helpful?