AI agents for Redis
Fast state for coordination between workflow runs. AGNT connects to Redis so agents can read what happens there, reason about it, and act — with a receipt for every run.
Redis and AGNT, in brief
| What it does | Lets an AGNT agent read from and act in Redis. |
|---|---|
| Connects with | Bearer — held in the local vault |
| AGNT node | custom-api, or the zapier-action bridge |
| Runs when | A key changes |
| Typical build time | Ten minutes |
| Where data goes | Nowhere by default — AGNT runs on your machine and credentials never leave it. |
What you can automate
Reacts when…
- a key changes
- a queue receives work
Agents can…
- read and write keys
- manage queues and counters
Teams use it for
- dedupe work across runs
- rate-limit outbound actions
- share state between agents
Build it: the Redis workflow
Most Redis builds begin the same way. A run starts when a key changes. The agent reads what arrived, judges it against criteria you wrote in plain language, and acts only where that judgment says it should — typically to read and write keys. That is what makes dedupe work across runs something you can hand over rather than merely schedule.
The shape is deliberately small. A trigger watching Redis, an agent that judges what arrived, and one action taken only when that judgment warrants it. Everything below is the actual definition, not an illustration of one.
{
"id": "ae732ef4-776b-41b9-aff6-ef199ca49416",
"name": "Redis — read, decide, act",
"nodes": [
{
"id": "6451981a-a397-443a-a613-dadee53b9818",
"text": "Run on a schedule",
"x": 512,
"y": 144,
"isEditing": false,
"type": "trigger-timer",
"icon": "clock",
"category": "trigger",
"isSelected": false,
"parameters": {
"interval": "15",
"unit": "minutes"
},
"description": "Checks Redis every fifteen minutes.",
"error": null,
"isActive": false,
"output": null,
"outputs": {}
},
{
"id": "d37bd4c4-3143-4f47-a6ca-cd1fc4967c1e",
"text": "Work out what should change",
"x": 512,
"y": 336,
"isEditing": false,
"type": "agnt-agent",
"icon": "agnt",
"category": "action",
"isSelected": false,
"parameters": {
"instructions": "Decide what needs to happen in Redis. Explain your reasoning."
},
"description": "Decides what needs to happen in Redis, and why.",
"error": null,
"isActive": false,
"output": null,
"outputs": {}
},
{
"id": "4c5695b2-01fb-46f4-aaf4-95142bf1c2b8",
"text": "Call the Redis API",
"x": 512,
"y": 528,
"isEditing": false,
"type": "custom-api",
"icon": "connect",
"category": "action",
"isSelected": false,
"parameters": {
"url": "https://{endpoint}.upstash.io/set/{key}/{value}",
"method": "POST",
"authType": "Bearer",
"headers": "{\"Content-Type\": \"application/json\"}"
},
"description": "POST against the Redis API, authenticated with bearer.",
"error": null,
"isActive": false,
"output": null,
"outputs": {}
}
],
"edges": [
{
"id": "fad2789a-af67-439f-af8d-8769949e5eea",
"start": {
"id": "6451981a-a397-443a-a613-dadee53b9818",
"type": "output"
},
"end": {
"id": "d37bd4c4-3143-4f47-a6ca-cd1fc4967c1e",
"type": "input"
},
"startX": 800,
"startY": 168,
"endX": 512,
"endY": 360
},
{
"id": "9c8b87a6-372a-4800-a2ef-6b261bccea84",
"start": {
"id": "d37bd4c4-3143-4f47-a6ca-cd1fc4967c1e",
"type": "output"
},
"end": {
"id": "4c5695b2-01fb-46f4-aaf4-95142bf1c2b8",
"type": "input"
},
"startX": 800,
"startY": 360,
"endX": 512,
"endY": 552
}
],
"zoomLevel": 1,
"canvasOffsetX": 0,
"canvasOffsetY": 0,
"isTinyNodeMode": false
}Run this against your own Redis
No account needed to run it. Every step writes a receipt you can read line by line afterwards.
State between runs
Workflows that run repeatedly need somewhere to remember what they already did. Redis is the pragmatic answer for deduplication, counters and cursors — the small pieces of state that stop a run from processing the same item twice.
Coordination and rate limiting
It also mediates between concurrent runs: queues for work handed between agents, and counters that keep outbound actions inside an external API’s limits rather than discovering them the hard way.
How to reach Redis from a workflow
Reaching Redis means one custom-api node rather than a purpose-built one. The endpoint and its bearer credentials are all it needs, and the zapier-action bridge covers it too if you would rather not hand-roll the request.
| What you need | Value |
|---|---|
| Endpoint | https://{endpoint}.upstash.io/set/{key}/{value} |
| Method | POST |
| Authentication | Bearer |
| Header | Authorization: Bearer {restToken} |
| Reference | Redis API documentation |
Worth knowing: Core Redis speaks RESP over TCP, not HTTP. This is Upstash’s REST layer, which is the practical way to reach Redis from a workflow node.
The part that catches people out
Core Redis speaks RESP over TCP, not HTTP. This is Upstash’s REST layer, which is the practical way to reach Redis from a workflow node.
That single detail accounts for most of the time people lose on a first Redis build. With it out of the way the endpoint above is all you need, and the workflow below wires it up.
Connect Redis in two minutes
- Download AGNT Community Core — free, local-first, no account needed to run.
- Connects to your local instance directly — no cloud account required, nothing leaves your machine.
- Drop the Redis node into a workflow or hand it to an agent — the first run produces a receipt you can read line by line.
Redis + AGNT — common questions
Why would a workflow need Redis?
To avoid repeating work across runs, to rate-limit outbound calls, and to share state between agents.
Does it need to be hosted?
A local instance is fine, and keeps the whole stack on your machine.
What can trigger a run?
A key changing or a queue receiving work.
