Two agents agreeing on one fact

The problem

Your scheduled task runs at nine. Your chat session happens at eleven. Claude Code runs on your laptop in between. As far as any of them can tell, the other two do not exist — a model has no channel to another model's conversation, and closing a session takes everything in it with it.

So you end up being the integration. You read something in one conversation and paste it into another, which works until you are asleep or the schedule fires while you are not looking.

The pattern

A keyspace belongs to an account, not to a connector. Anything authenticated as you sees the same keys, so one conversation can leave a note for the next one:

# Morning scheduled run finds something it cannot decide:
set_value("triage:needs-review", "PR 481 touches billing", ttl: 86400)

# Later, in a chat session:
list_keys(prefix: "triage:")
→ { total: 1, keys: [{ key: "triage:needs-review", ... }] }

get_value("triage:needs-review")
→ { exists: true, value: "PR 481 touches billing" }

The TTL matters here. A handoff that nobody picks up should expire rather than sit in your keyspace forever pretending to be current.

Which way the work flows

Scheduled job to you

The most useful direction. A job that hits something it should not decide alone writes what it found and stops. Start your next session by asking what is waiting:

Check Junkt for any keys under the "triage:" prefix and
tell me what is waiting for a decision.

You to a scheduled job

The reverse works too. Approve something in chat, and the next scheduled run acts on it without you being awake:

set_value("deploys:approved", "v2.4.1")

Tell the scheduled agent to look for that key, act, and delete it — so an approval is consumed once rather than acted on every morning until you notice.

Machine to machine

Claude Code on a laptop and a Cowork task in the cloud share a keyspace too. State written from one worktree is readable from another, and from a scheduled run while the laptop is shut.

Give the shared keys a shape

Handoff keys are read by something that did not write them, so the naming has to carry more meaning than usual. A prefix per purpose, and a value the reader can act on without guessing:

triage:needs-review      something wants a human decision
deploys:approved         a human decided something
runs:last_error          the last thing that went wrong
notes:for-next-session   free text, expires in a day

Keep the value self-describing. "PR 481 touches billing" is useful to a fresh conversation in a way that "481" is not.

Everything you connect sees everything

Being plain about this: there is one keyspace per account, and every connector you approve can read and write all of it. There is no per-connector scoping and no read-only token. That is what makes the handoff work, and it is also the reason not to put anything in Junkt you would not want any connected agent to read.

Your dashboard lists every connector with the date you approved it. Revoking one stops it on its next call and leaves your keys untouched. The activity log shows which mutations came from MCP and which from the web UI, which is how you tell a scheduled run's writes from your own.

Worth knowing

• Put a TTL on anything conversational. A note left for a session that never happened should go away on its own.
• Have the reader delete what it consumes. Otherwise an approval gets acted on repeatedly.
• Two writers, one key, needs care. If both sides might write at once, use increment rather than read-modify-write.
• No notifications. Junkt will not tell a session that something appeared; whoever is interested has to look. Asking at the start of a session is the whole mechanism.