From 7b7b1b846f8d708b8ee22fc14e75e4f8ed2eeac9 Mon Sep 17 00:00:00 2001 From: rkoster Date: Thu, 17 Sep 2026 09:44:49 +0200 Subject: [PATCH 1/4] docs: define reactive agents research note --- ...026-09-17-infinity-research-note-design.md | 62 +++++++++++++++++++ 1 file changed, 62 insertions(+) create mode 100644 docs/superpowers/specs/2026-09-17-infinity-research-note-design.md diff --git a/docs/superpowers/specs/2026-09-17-infinity-research-note-design.md b/docs/superpowers/specs/2026-09-17-infinity-research-note-design.md new file mode 100644 index 0000000..d4264f7 --- /dev/null +++ b/docs/superpowers/specs/2026-09-17-infinity-research-note-design.md @@ -0,0 +1,62 @@ +# Reactive Agents Research Note Design + +## Goal + +Add a sourced comparative research note on Hydro Project's Infinity runtime and Reactive +Agent Protocol (RAP), MCP Tasks, and the experimental MCP Triggers & Events work, with an +architecture-first assessment of relevance to Cloud Foundry. + +## Scope + +The note will describe documented behavior from each upstream project, then clearly separate +Cloud Foundry analysis from upstream facts. It will cover: + +- Infinity as a Rust agent runtime and reference implementation of RAP. +- Execution slices, durable conversation/state reconstruction, message-driven wake-ups, + tool dispatch, callbacks, subscriptions, hibernation, and per-thread ordering. +- RAP's asynchronous tool contract and its relationship to synchronous MCP tools. +- Infinity's MCP compatibility layer and serverless deployment model. +- MCP Tasks as an official MCP extension with durable task state, receiver-generated task + IDs, polling, and deferred result retrieval; identify the `2026-07-28` schema as stable + according to its repository. +- MCP Triggers & Events as an explicitly experimental working group exploring proactive + server notifications, polling, streams, webhooks, subscription TTLs, cursors/replay, + signatures, delivery semantics, and ordering guarantees. +- The semantic differences and possible overlap between task lifecycles, event + subscriptions, and reactive agent execution. +- Cloud Foundry relevance across Diego process lifecycle, CAPI-managed applications, + external queues and state stores, scale-to-zero, and Loggregator observability. +- Open questions about convergence versus fragmentation, polling versus push/webhooks, + callback authentication, delivery guarantees, ordering and deduplication, replay/cursors, + state-store integration, cost semantics, and independent protocol adoption. + +## Structure + +Create `research/infinity.md` using the repository template and required sections: + +1. Summary +2. Key findings +3. CF relevance +4. Open questions + +The frontmatter will include the author, current date, relevant tags, `status: draft`, +primary Infinity/RAP and MCP extension sources, and provisional ratings with concise +justifications. + +## Sources and evidence + +Use the Infinity GitHub repository and README, runtime overview, runtime architecture, +Reactive Agent Protocol overview, RAP specification overview, and Lambda deployment +documentation. Also use the MCP Tasks repository and README, plus the MCP Triggers & Events +repository, README, and draft design sketch. The note will identify MCP Tasks as an official +extension repository, Triggers & Events as experimental, and will not describe RAP as an AAIF +or generally ratified standard unless an authoritative source establishes that status. Cloud +Foundry claims will be framed as analysis or open questions rather than presented as existing +integration. + +## Validation + +Run the repository's configured note validation and test script. Confirm that the new file +has valid frontmatter, a kebab-case filename, all required sections, linked sources, no +template placeholders, and only the intended tracked changes are committed and pushed in a +new PR. From a6735ac445aca7f7a8476f3c731581da1d4a4f31 Mon Sep 17 00:00:00 2001 From: rkoster Date: Thu, 17 Sep 2026 09:46:44 +0200 Subject: [PATCH 2/4] docs: add reactive agents research note --- .../2026-09-17-infinity-research-note.md | 140 ++++++++++++++++++ research/infinity.md | 137 +++++++++++++++++ 2 files changed, 277 insertions(+) create mode 100644 docs/superpowers/plans/2026-09-17-infinity-research-note.md create mode 100644 research/infinity.md diff --git a/docs/superpowers/plans/2026-09-17-infinity-research-note.md b/docs/superpowers/plans/2026-09-17-infinity-research-note.md new file mode 100644 index 0000000..c0e1945 --- /dev/null +++ b/docs/superpowers/plans/2026-09-17-infinity-research-note.md @@ -0,0 +1,140 @@ +# Reactive Agents Research Note Implementation Plan + +> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking. + +**Goal:** Add and publish a sourced comparative research note on Infinity/RAP, MCP Tasks, and MCP Triggers & Events, including Cloud Foundry relevance. + +**Architecture:** Create one flat Markdown note under `research/`, following the repository template. Organize it around three related layers: Infinity/RAP reactive execution, MCP Tasks durable task state, and experimental MCP Triggers & Events delivery. Compare their semantics and map the resulting requirements to Cloud Foundry capabilities and gaps. + +**Tech Stack:** Markdown, YAML frontmatter, Devbox, repository note validator, Git, GitHub CLI. + +--- + +### Task 1: Create the comparative reactive agents research note + +**Files:** +- Create: `research/infinity.md` + +- [ ] **Step 1: Add valid frontmatter** + +Use `title: "Reactive Agents: Infinity/RAP and MCP Asynchronous Extensions"`, author `Ruben Koster (@rkoster)`, date `2026-09-17`, tags covering `orchestration`, `durable-execution`, `inter-agent-comms`, `event-driven`, and `ecosystem-survey`, `cf_areas: [capi, diego, loggregator]`, and `status: draft`. Add provisional ratings from 0-100 with concise justifications. Link the Infinity repository, README, runtime overview, runtime architecture, RAP overview, RAP specification overview, and Lambda deployment documentation; the MCP Tasks repository and README; and the MCP Triggers & Events repository, README, and design sketch. + +- [ ] **Step 2: Write the Summary section** + +Explain that Infinity is a Rust framework for highly concurrent agents and the reference runtime for RAP. State that it models work as short execution slices: load durable state, process a message and model completion, dispatch asynchronous tool calls, persist state, and yield. Introduce MCP Tasks as an official extension for durable call-now/fetch-later task state, and Triggers & Events as explicitly experimental work on proactive server notifications. Mention that MCP compatibility preserves existing synchronous tools while these extensions and RAP target long-running and event-driven work. + +- [ ] **Step 3: Write the Key findings section** + +Cover these sourced findings as bullets: + +1. Every Infinity input is an `InputMessage`, including user text, tool results, subscription events, child-thread reports, OAuth challenges, and timer wake-ups; a `group_id` identifies the conversation thread. +2. An Infinity slice loads conversation history and processed-message state, prepares and deduplicates inputs, runs a model completion, dispatches a tool call, persists state, and ends without waiting on external work. +3. RAP uses HTTP POST messages: the runtime sends a tool invocation with a callback URL, the tool acknowledges immediately, and later posts a result or event back to the runtime. The callback becomes the next wake-up message. +4. RAP makes long-running calls, subscriptions, webhooks, human approvals, and hibernating agents first-class. When no work is pending, the agent process can shut down and resume when a message arrives. +5. RAP uses per-thread ordering and durable state to tolerate at-least-once delivery, redelivery, restarts, and cold starts; the note should identify ordering and deduplication as important implementation mechanisms rather than assume exactly-once execution. +6. The MCP Tasks extension defines durable task state machines with receiver-generated task IDs, status inspection, polling, and deferred result retrieval. The repository identifies `2026-07-28` as a stable schema snapshot and the extension as based on SEP-2663. +7. MCP Triggers & Events is explicitly experimental. Its working group explores `events/list`, poll, stream, and webhook delivery modes, subscription TTLs, cursors and replay, event IDs for deduplication, webhook signatures, and cross-transport ordering guarantees; its draft design is not an official MCP recommendation. +8. MCP remains useful for fast request/response tools, and Infinity can run MCP servers through a compatibility layer. RAP changes the waiting contract, MCP Tasks adds task lifecycle state, and Triggers & Events explores proactive event delivery; these primitives overlap but are not interchangeable. +9. Infinity's Lambda deployment maps one slice to a short-lived invocation, with SQS FIFO for ordered input, Aurora DSQL for durable state, Bedrock for model calls, and a receiver Lambda for RAP callbacks. This is an Infinity deployment architecture, not a Cloud Foundry integration. +10. Infinity, RAP, and the MCP extensions address asynchronous agent/tool interaction, not provider routing, general application ingress, or every workflow orchestration concern. + +- [ ] **Step 4: Write the CF relevance section** + +Map the three approaches to Cloud Foundry explicitly as analysis. Explain that Diego is well suited to supervising resident Infinity processes, but reactive hibernation and scale-to-zero need a message-triggered activation mechanism that ordinary CF application routing does not provide. CAPI could manage an agent application and its binding metadata, while an external queue and durable state store would be required for wake-ups, ordering, and persistence. Discuss whether a CF-managed callback/event receiver or brokered event gateway could translate RAP callbacks, MCP task completions, and MCP event webhooks into queue messages. Include Loggregator implications for correlating one logical agent turn across multiple short processes, tool callbacks, retries, polling, and asynchronous events. Note that applications on CF could run the Infinity Rust library or a compatible MCP service, but a platform offering would need callback authentication, tenant isolation, delivery/retry policies, replay behavior, task/event state, and state-store integration. + +- [ ] **Step 5: Write the Open questions section** + +Ask whether CF should provide a common durable input/event substrate for reactive agents; whether it should expose RAP, MCP Tasks, MCP Triggers & Events, or an implementation-neutral abstraction; how callback and webhook authentication and tenant routing should work; which delivery, ordering, deduplication, replay, and retry guarantees the platform should expose; whether CF should support scale-to-zero activation or focus on resident processes; how task state, subscriptions, state stores, and timers should be provisioned; how asynchronous usage should appear in Loggregator and billing; and whether RAP should be adopted independently of Infinity's Rust runtime. + +### Task 2: Validate the note + +**Files:** +- Test: `.github/scripts/validate_notes.py` +- Test: `devbox.json` + +- [ ] **Step 1: Run configured validation** + +Run: + +```bash +devbox run validate +``` + +Expected: successful validation with all research notes and ideas reported valid, including `research/infinity.md`. + +- [ ] **Step 2: Run configured test script** + +Run: + +```bash +devbox run test +``` + +Expected: the same note validation completes successfully through the repository's configured test script. + +- [ ] **Step 3: Inspect the diff** + +Run: + +```bash +git diff --check +``` + +Expected: no whitespace errors; only the intended note and approved design/plan artifacts are staged, while unrelated environment artifacts remain untouched. + +### Task 3: Commit the note and create the PR + +**Files:** +- Create: `research/infinity.md` +- Include: `docs/superpowers/specs/2026-09-17-infinity-research-note-design.md` +- Include: `docs/superpowers/plans/2026-09-17-infinity-research-note.md` + +- [ ] **Step 1: Stage only intended files** + +Run: + +```bash +git add research/infinity.md +``` + +Expected: only the comparative note and its approved design/plan documents are staged. + +- [ ] **Step 2: Commit the note** + +Run: + +```bash +git commit -m "docs: add reactive agents research note" +``` + +Expected: one commit containing the research note and approved planning artifacts. + +- [ ] **Step 3: Push the branch** + +Run: + +```bash +git push -u origin research/infinity +``` + +Expected: the `research/infinity` branch is available on origin without unrelated files. + +- [ ] **Step 4: Open the PR** + +Run: + +```bash +gh pr create --base main --head research/infinity --title "docs: add reactive agents research note" --body-file /tmp/infinity-pr-body.md +``` + +The PR body must describe Infinity/RAP, MCP Tasks, MCP Triggers & Events, the comparison, and Cloud Foundry relevance, and confirm the repository checklist. + +- [ ] **Step 5: Verify the PR** + +Run: + +```bash +gh pr view --json number,url,title,baseRefName,headRefName,state,statusCheckRollup +``` + +Expected: an open PR from `research/infinity` into `main`, with the validation check visible and the final URL recorded for the user. diff --git a/research/infinity.md b/research/infinity.md new file mode 100644 index 0000000..b0ccca3 --- /dev/null +++ b/research/infinity.md @@ -0,0 +1,137 @@ +--- +title: "Reactive Agents: Infinity/RAP and MCP Asynchronous Extensions" +author: Ruben Koster (@rkoster) +date: 2026-09-17 +tags: [orchestration, durable-execution, inter-agent-comms, event-driven, ecosystem-survey] +cf_areas: [capi, diego, loggregator] +status: draft +ratings: + platform-impact: + value: 82 + note: "Asynchronous tasks and event-driven wake-ups could make long-running agents a first-class workload for Cloud Foundry, but require platform-managed messaging and durable state." + maturity: + value: 58 + note: "Infinity has a concrete runtime and RAP specification, MCP Tasks has a stable schema snapshot, while MCP Triggers & Events remains explicitly experimental." + novelty: + value: 88 + note: "The execution-slice model treats waiting, callbacks, subscriptions, and hibernation as protocol and runtime primitives rather than application-specific polling patterns." + actionability: + value: 76 + note: "The patterns identify concrete CF integration points around queues, state, callbacks, ordering, and observability, even though no direct CF integration is documented." +sources: + - https://github.com/hydro-project/infinity + - https://infinity.hydro.run/docs/infinity-runtime/overview + - https://infinity.hydro.run/docs/infinity-runtime/architecture + - https://infinity.hydro.run/docs/rap/what-is-rap + - https://infinity.hydro.run/docs/rap/spec/overview + - https://infinity.hydro.run/docs/infinity-runtime/deploying-on-lambda + - https://github.com/modelcontextprotocol/ext-tasks + - https://github.com/modelcontextprotocol/experimental-ext-triggers-events + - https://raw.githubusercontent.com/modelcontextprotocol/experimental-ext-triggers-events/main/docs/design-sketch-proposal.md +--- + +## Summary + +Infinity is a Rust framework for highly concurrent agents and the reference runtime for the +Reactive Agent Protocol (RAP). It models work as short execution slices: load durable state, +process a message and model completion, dispatch an asynchronous tool call, persist state, +and yield. MCP Tasks provides an official MCP extension for durable call-now/fetch-later task +state, while the explicitly experimental Triggers & Events work explores proactive server +notifications. Together, these projects show several complementary ways to make long-running +and event-driven agent work possible without holding an agent process open. + +## Key findings + +- **Infinity makes every wake-up a message.** Its `InputMessage` covers user text, tool + results, subscription events, child-thread reports, OAuth challenges, and timer wake-ups. + A `group_id` identifies the conversation thread, allowing the runtime to use one message + processing model for interactive and externally triggered work. +- **Execution happens in non-blocking slices.** A slice restores conversation history and + processed-message state, deduplicates inputs, runs a model completion, dispatches a tool + call, persists the remaining state, and ends without waiting for external work. The next + message reconstructs the state needed for continuation. +- **RAP uses an asynchronous callback contract.** The runtime sends a tool invocation over + HTTP with a callback URL. The tool acknowledges immediately, and later posts a result or + event to the callback. That callback is consumed as a new wake-up message rather than as a + response on the original connection. +- **Waiting is a first-class agent behavior.** RAP supports long-running calls, + subscriptions, webhooks, human approvals, and hibernating agents. When no work is pending, + the agent process can shut down and resume when a user message, tool result, subscription + event, or timer message arrives. +- **Durability does not imply exactly-once execution.** Infinity documents per-thread + ordering, durable state, and deduplication of processed message IDs for infrastructure with + at-least-once delivery. Redelivery, restarts, and cold starts are expected conditions, so + applications still need idempotent effects and clear retry behavior. +- **MCP Tasks standardizes deferred task retrieval.** The official `io.modelcontextprotocol/tasks` + extension describes tasks as durable state machines with receiver-generated task IDs. It + supports call-now/fetch-later workflows such as expensive computation, batch processing, + and external jobs. Its repository identifies the `2026-07-28` schema directory as a stable + snapshot and bases the extension on SEP-2663. +- **MCP Tasks and RAP emphasize different boundaries.** MCP Tasks adds task lifecycle state, + status inspection, polling, and deferred result retrieval to MCP. RAP defines a fire-and- + forget tool invocation and callback path designed for a runtime that can hibernate. A task + can be used by a reactive runtime, but the two concepts are not interchangeable. +- **Triggers & Events explores proactive delivery.** The MCP Triggers & Events repository is + explicitly an experimental incubation space, not an official MCP specification or + recommendation. Its working group is exploring event discovery, poll and stream delivery, + webhook callbacks, subscription TTLs, opaque cursors and replay, event IDs for deduplication, + webhook signatures, and ordering guarantees across transports. +- **The experimental event design complements task state.** Tasks answer "what is the status + of this deferred operation and when can I fetch its result?" Events answer "how does a client + learn that something happened without polling or holding a stream open?" A reactive agent + may need both, but the delivery, authorization, retention, and replay policies differ. +- **MCP remains useful for fast tools.** Infinity can run MCP servers through a compatibility + layer. RAP changes the waiting contract for tools, MCP Tasks adds a durable task lifecycle, + and Triggers & Events explores server-initiated event delivery; none is a replacement for + all of the existing MCP tool ecosystem. +- **Infinity has a concrete serverless deployment model.** Its Lambda architecture maps one + execution slice to a short-lived invocation, uses SQS FIFO for ordered input, Aurora DSQL + for durable state, Bedrock for model calls, and a receiver Lambda for RAP callbacks. This + demonstrates one implementation of the pattern, not an existing Cloud Foundry integration. +- **The scope is agent/tool interaction.** Infinity, RAP, and the MCP extensions address + asynchronous execution and communication. They do not provide general model-provider + routing, application ingress, or every workflow orchestration capability a platform may + need. + +## CF relevance + +Cloud Foundry can run a resident Infinity process or another RAP-compatible service as an +application, with CAPI managing application metadata and Diego supervising the process. That +deployment would not automatically provide hibernation or scale-to-zero: ordinary CF routing +delivers incoming HTTP traffic to running instances, while a reactive runtime needs an event or +message to activate work after the process has stopped. + +A platform implementation would likely need an external or CF-managed queue and durable state +store for wake-ups, per-thread ordering, deduplication, task state, subscriptions, and timers. +A callback or event receiver could translate RAP callbacks, MCP task completions, and MCP event +webhooks into queue messages. Service bindings could expose those endpoints and credentials to +applications, while platform policy controls callback authentication, tenant routing, retry +limits, replay, and isolation between spaces. + +The model also changes observability requirements. Loggregator-compatible logs and metrics +would need to correlate one logical agent turn across multiple short-lived processes, model +calls, tool callbacks, retries, polling, and external events. If the platform exposes a common +reactive-agent substrate, it would need to make delivery guarantees and failure semantics +visible to operators rather than hide them behind an apparently synchronous application API. +The most direct CF opportunity may therefore be a durable event and activation service that +supports multiple runtimes and protocols, rather than choosing Infinity, RAP, MCP Tasks, or +Triggers & Events as the sole platform abstraction. + +## Open questions + +- Should Cloud Foundry provide a common durable input and event substrate for reactive agents, + or should teams provision queues and state stores themselves? +- Should a CF platform offering expose RAP, MCP Tasks, MCP Triggers & Events, or an + implementation-neutral abstraction over tasks, callbacks, and subscriptions? +- How should callback and webhook authentication, tenant routing, subscription ownership, and + cross-space isolation work? +- Which delivery, ordering, deduplication, replay, and retry guarantees should the platform + expose, and how should applications declare idempotency requirements? +- Should CF support message-triggered scale-to-zero activation, or focus on resident processes + and let an external serverless substrate provide hibernation? +- How should task state, event subscriptions, durable cursors, state stores, and timers be + provisioned and billed? +- How should asynchronous agent activity appear in Loggregator, tracing, usage accounting, and + operator-facing failure events? +- Can RAP be adopted independently of Infinity's Rust runtime, and can the MCP extensions + converge with reactive-agent implementations without fragmenting the tool ecosystem? From 071d1a272baa8c573e965dd6da783c26ebe88a35 Mon Sep 17 00:00:00 2001 From: rkoster Date: Sat, 19 Sep 2026 16:29:25 +0200 Subject: [PATCH 3/4] docs: update generated research map --- generated/research-map.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/generated/research-map.html b/generated/research-map.html index bbe5f21..75016a8 100644 --- a/generated/research-map.html +++ b/generated/research-map.html @@ -23,9 +23,9 @@

Focus use cases

Attested Workload Authority and Mediated Tool AccessExchange platform-attested workload identity for scoped authority while credentials and outbound tool access remain mediated by the platform.Strategic decision: Decide whether CF should become the portable trust and policy layer between agent workloads and the tools they invoke.
Gap, experiments, and evidence
Current CF gap
CF issues workload identity certificates but does not exchange them for scoped tool authority, keep third-party credentials out of workloads, mediate off-platform access, or record delegation-aware audit events.
Candidate POC
Exchange a Diego instance identity certificate for a short-lived scoped token, invoke one allowed tool through a credential proxy and egress mediator, deny another, and emit attributable audit events.
Candidate RFC scope
Define workload token exchange, authority and delegation claims, credential brokering, outbound mediation and policy enforcement, audit events, revocation, and integration boundaries for UAA, routing, and service brokers.

Core

Supporting

-
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
+
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
 -