⚙️ Builder Lane
Task & Workflow Automation
A workflow agent that knows its operational environment handles tasks a stateless agent can't touch. Which tools connect to what. Where things break. What approvals are needed. The agent builds this model from runs — humans add the institutional context only they can provide.
Autonomous
Agent maps the environment. Learns integrations, failure modes, and patterns from every run. Operational model builds itself.
+
Controlled
You seed the constraints. Approval chains, permissions, service maps. Use when precision and auditability matter.
Overview
Workflow agents lose time to context loss — rediscovering what integrations are live, what broke last time, which steps need approval. Nervous Machine gives the workflow agent an evolving operational model that accumulates rather than resets. The agent builds it from runs; operators seed the constraints they need enforced from day one.
Autonomous Mode
Add this to your workflow agent's system prompt. The agent builds its operational model from runs — learning what works, what fails, and what the environment looks like. Operators align via chat when context drifts.
System prompt — workflow agent
## Nervous Machine — Workflow Context
You have access to Nervous Machine tools. User ID: {USER_ID}
SESSION START:
1. Call get_pod_summary for this user.
2. Call get_service_context to check integration status.
3. Call get_agent_context for agent_id: {AGENT_ID},
context_type: task_history to review recent runs.
DURING RUNS — observe and save:
- New tool or service integrations → entity events
(include auth type, permissions, and any write restrictions)
- Approval requirements discovered → claim events
(include threshold, approver, and SLA in meta)
- Recurring failures or edge cases → pattern events
(include workaround and first-seen in meta)
- Current service health issues → save_service_context
AFTER EACH RUN:
1. Call save_agent_context with context_type: task_history.
Include what completed, what failed, and why.
2. Save any new patterns or constraints discovered.
3. Call update_session with interactions=1 — exactly once.
✦
Approval chains are the most important thing to get right. If the agent discovers an approval requirement mid-run, it should save it immediately — not wait for shutdown. The next run will respect it from the start.
Controlled Mode
Use controlled saves to seed the operational model before the first run — so the agent starts with known constraints rather than discovering them the hard way.
Tool Integrations
Seed integration map explicitly
await call_pod("save_event", {
"user_id": user_id,
"key": "salesforce-crm",
"signal_type": "entity",
"value": 1.0,
"certainty": 0.95,
"gloss": "Salesforce connected via OAuth. Agent is read-only. All writes require human approval.",
"meta": {
"auth_type": "oauth",
"agent_permissions": "read",
"write_approval_required": True,
"approver": "ops-lead",
"approval_sla_hours": 4
}
})
Approval Chains
Approval requirements are claims — absolute rules the agent must respect. Seed them explicitly so the agent never has to discover them by violating them.
Seed approval rules
await call_pod("save_event", {
"user_id": user_id,
"key": "payment-approval-required",
"signal_type": "claim",
"value": 1.0,
"certainty": 0.99, # high — this is a hard rule
"gloss": "Any payment over $500 requires finance approval. Under $500 is autonomous.",
"meta": {
"threshold_usd": 500,
"approver": "finance@acme.com",
"sla_hours": 4,
"escalation": "cfo@acme.com if no response in 4h"
}
})
Link approval chain to integration
await call_pod("link_events", {
"user_id": user_id,
"source_key": "payment-approval-required",
"source_signal_type": "claim",
"target_key": "salesforce-crm",
"target_signal_type": "entity",
"relationship": "PART_OF",
"note": "Payment approval rule governs all Salesforce write operations"
})
Service Context
Track the health of services the workflow depends on. The agent checks this at session start and can skip or reroute steps when a dependency is degraded.
Update service health — agent does this autonomously after each run
await call_pod("save_service_context", {
"user_id": user_id,
"service_name": "payment-gateway",
"status_data": {
"status": "degraded",
"last_checked": "2025-11-15T14:32:00Z",
"known_issues": ["High latency on EU endpoints"],
"fallback": "stripe-backup"
}
})
Task History
Save what each run did, decided, and encountered. The next run picks up with full context of what came before — including failures and the reasons behind them.
Save run history — agent does this at shutdown
await call_pod("save_agent_context", {
"user_id": user_id,
"agent_id": "invoice-workflow",
"context_type": "task_history",
"data": {
"task": "Process November invoices",
"completed": 47,
"failed": 3,
"failure_reason": "Vendor ID mismatch on EU invoices (legacy pre-2023 format)",
"flagged_for_review": ["INV-2041", "INV-2089"],
"duration_minutes": 12
}
})
Failure Patterns
When a run fails in a recurring way, save it as a pattern. The agent learns to anticipate it — checking preconditions, choosing fallbacks, or surfacing it to a human before it cascades.
Save a recurring failure — agent or operator
await call_pod("save_event", {
"user_id": user_id,
"key": "eu-invoice-vendor-mismatch",
"signal_type": "pattern",
"value": 0.8,
"certainty": 0.75,
"gloss": "EU invoices with pre-2023 vendor ID format fail matching. Route to manual review.",
"meta": {
"first_seen": "2025-09",
"frequency": "~5% of EU invoices",
"workaround": "manual-review queue",
"fix_status": "backlog — vendor migration Q1 2026"
}
})
Human Alignment
Operational context lives in people's heads — approval chains from six months ago, vendor quirks learned through painful experience, integration constraints from contracts. The agent builds what it encounters. Operators add what it can't observe.
Adding undocumented constraints
Please save to my workflow pod that the legal team reviews all new vendor contracts before any integration goes live. That's not written down anywhere but it's always required.
Updating stale state
The Stripe backup integration was deprecated last month. Please remove it from the service context and update the payment fallback.
Auditing what the agent knows
What does my workflow pod know about the invoice process? What failure patterns is it tracking? Show me the approval chain constraints.