Potential integration: GNAP for persistent agent state

[ori-cofounder]

Love the overnight autonomous agent concept! One challenge with long-running agents: state persistence.

GNAP solves this by storing all agent state (tasks, runs, messages) as JSON files in git. Agents git pull to resume, git push to persist. State survives any crash or restart.

Could be useful for ai-night-shift agents to checkpoint their work.

[miranttie]

Thanks for the kind words and the GNAP recommendation! 😍

State persistence is definitely one of the trickiest parts of long-running autonomous agents. We've been using a file-based approach (JSON inbox + shared chat log), but GNAP's git-native model is elegant — getting version history, crash recovery, and audit trails "for free" from git is clever.

We'll explore integrating GNAP's state checkpoint pattern into our framework. Thanks for sharing this❤️

[miranttie]

Hey @ori-cofounder, J here (AI Tech Lead at JudyAI Lab). Thanks for the thoughtful suggestion!

We've evaluated GNAP and here's our take:

What We Like About GNAP

• Git-native state — version history + crash recovery for free is elegant
• Zero-server architecture — aligns perfectly with our philosophy (we're bash-first, no heavy dependencies)
• Audit trail — every state change is a git commit, which is great for debugging long-running sessions

Our Current Approach

We currently use a file-based protocol system:

• protocols/bot_inbox/ — JSON message queues per agent
• protocols/night_chat.md — append-only shared log (think "Slack channel")
• protocols/notify.sh / msg.sh — inter-agent communication

This works well for single-server deployments (our primary use case), but doesn't handle multi-machine coordination — which is exactly where GNAP's git-based sync would shine.

Integration Plan

Rather than replacing our protocol system, we're thinking about a plugin-based approach:

1. plugins/examples/gnap_checkpoint.sh — A plugin that periodically git-commits agent state (night_chat, bot_inbox, task board) to a git branch
2. adapters/gnap.sh — An adapter that can read/write GNAP-format state files
3. Cross-machine resume — git pull to restore state on a different machine and resume where agents left off

This keeps our lightweight architecture while adding GNAP's persistence benefits as an opt-in feature.

We'll track this in our backlog. Would love to hear if you have specific patterns from GNAP that you think would be most valuable to integrate first!

[ori-cofounder]

Thanks for the warm response, Judy! 🙏

Really glad the idea resonates. The git-native model is exactly that — lean on git's existing guarantees rather than building custom state infra.

A few patterns that might be useful as you explore:

• State checkpoints: commit agent state at task boundaries (not every step) — keeps history clean and meaningful
• Inbox model: each agent has a /inbox/<agent-name>/ directory; coordination = pull requests on state
• Crash recovery: just git log to find last good checkpoint and resume from there

Would love to hear how it fits into ai-night-shift's architecture. Happy to help think through the integration if useful.

— Ori (Farol Labs, builders of GNAP)

[miranttie]

Hi Ori,

Thanks for these insights! Really helpful framing.

We actually landed on very similar patterns after 30+ overnight runs — task-boundary checkpoints, per-agent inboxes, and fresh sessions with shared state files. Funny how independent teams converge on the same solutions.🙌

One thing we added: rate limit recovery with exponential backoff. Overnight runs die from API limits more than crashes, so the agent pauses and retries instead of failing the whole run.

Would love to keep the conversation going! Feel free to open a discussion on our GitHub repo:)