How a pipe works

You ask your bot to watch things. A pipe is the written-down way it watches, so the same question follows the same steps every time.

Why your bot is better with pipes

Picture one request: tell me every morning if any of my tools shipped a security fix. Without a pipe, the bot starts over each time. With a pipe, that morning check is a fixed routine.

Example. Another everyday ask: “Alert me if BTC drops below $90k.”

What your bot saves

Measured Oct 18, 2026, on three checks: SEC 8-K filings, a 4-feed news digest, and a 7-symbol price snapshot. Method, table, and caveats.

A day with your bot

Example. These times illustrate a schedule. They are not a live run.

1. 7:00 Morning digest A note arrives: which of your tools shipped a security fix overnight.
2. 2:00 Price alert If BTC is under $90k, you get a short alert. Either way, the run leaves a receipt.
3. 6:00 You look The dashboard shows both runs, what each one checked, and the receipt.

Anatomy of a pipe

github-releases-digest watches GitHub release feeds. The diagram is the real step order. The values are example data from the recorded snapshot.

steps:
  - id: fetch
    block: fetch_http
    for_each: "${inputs.repos}"
    with:
      url: "https://github.com/${item}/releases.atom"
  - id: entries
    block: parse_rss
    in: "${steps.fetch}"
  - id: with_repo
    block: regex_extract
    in: "${steps.entries}"
  - id: unique
    block: dedupe
    in: "${steps.with_repo}"
  - id: new
    block: diff_since_last
    in: "${steps.unique}"
  - id: ordered
    block: sort
    in: "${steps.new}"
  - id: format
    block: format
    in: "${steps.ordered}"
output:
  text: "${steps.format.text}"
  count: "${steps.format.count}"

Example output

New releases:
- bytecodealliance/wasmtime dev (2026-10-16T21:32:02Z)
- bytecodealliance/wasmtime v49.0.3 (2026-10-14T17:17:37Z)
- tokio-rs/tokio tokio-1.53.3 (2026-10-13T20:49:48Z)

Example data, shortened from the committed snapshot. The full list is longer.

Run receipt

b3:32fcd8189b88e670634706ae5cc0ca8bb11e711f2eb0637dd614bbbabd621e29

That hash covers the pipe content id, the input hash, each step output hash, each recording hash, and the final output hash. pipes replay reruns the snapshot with no network and checks the same receipt. It does not include the run id or the wall clock.

Chaining pipes

release-radar does not fetch those feeds itself. It runs two published pipes, then merges their text. A sub-pipe keeps its own permissions. The parent must allow every host the children use.

permissions:
  network: [github.com, rustsec.org]
steps:
  - id: releases
    block: pipe:github-releases-digest@^0.1
    with:
      repos: "${inputs.repos}"
  - id: advisories
    block: pipe:security-advisories@^0.1
    with:
      keyword: "${inputs.keyword}"
  - id: rows
    block: merge
    with:
      lists:
        - - kind: releases
            text: "${steps.releases.text}"
        - - kind: advisories
            text: "${steps.advisories.text}"

[[pipes]]
name = "release-radar"

[pipes.pipes]
"github-releases-digest@^0.1" = "b3:461f0752b1e60498a29505f7cc490a067c99706ec05790b5dbf68f2b8b6a2361"
"security-advisories@^0.1" = "b3:a99d8390695e47234b980e82b71b35bd3754b8e081536837372a051e7b1df661"

Combined receipt

One hash covers the parent step and every nested step. Example data from one local run of release-radar. The feeds change, so a later run has a different receipt. Replay of that snapshot checks this same hash.

steps:
  - id: releases          block_version: b3:461f0752b1e60498a29505f7cc490a067c99706ec05790b5dbf68f2b8b6a2361
  - id: releases/fetch
  - id: releases/new
  - id: advisories        block_version: b3:a99d8390695e47234b980e82b71b35bd3754b8e081536837372a051e7b1df661
  - id: advisories/fetch
  - id: rows
  - id: digest
receipt: b3:60e9350ce3376611a3b8d71eb74a8fbb9a458f657a15b7cc51f72cb83c514c41

HTTP responses and state reads from both pipes are on the one tape. Replay checks every one of those hashes.

Nesting stops at 8 pipes. A cycle, or a child host the parent did not allow, fails validation.

How your agent calls it

{
  "name": "pipe__release-radar",
  "arguments": {
    "repos": ["tokio-rs/tokio"],
    "keyword": "wasmtime"
  }
}

{
  "status": "succeeded",
  "output": { "text": "Release radar\n\n…", "count": 2 },
  "receipt": "b3:…"
}

POST https://asipipes.com/mcp
Authorization: Bearer pk_live_…

Get pinged when something new happens

A webhook fires when a run's diff_since_last step finds new records. An empty run stays quiet. The POST body is JSON, so a Grok Bot routine can use the URL as its trigger.

curl -s -X POST https://asipipes.com/v1/notifications \
  -H "Authorization: Bearer $PIPES_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url":"https://example.com/hooks/asipipes","pipe":"github-releases-digest"}'

{
  "name": "add_notification",
  "arguments": {
    "url": "https://example.com/hooks/asipipes",
    "pipe": "github-releases-digest"
  }
}

import hashlib, hmac
def signed(secret, timestamp, body):
    mac = hmac.new(secret.encode(), timestamp.encode() + b"." + body, hashlib.sha256)
    return "sha256=" + mac.hexdigest()
ok = hmac.compare_digest(signed(secret, timestamp, raw_body), header)

Determinism in 3 bullets

• Same pipe content, same inputs, and the same lock produce the same output. The receipt is how you check.
• An LLM step is cached by a hash of the model, the prompt, and the item. The next run reuses that answer.
• --frozen turns a cache miss into an error, which is what you want in CI.

Open release-radar · Browse the library · API and MCP