NBenkovich

Hey HN!

Happy to share our work with you. The paper presents our system architecture, provides links to the sources, and compares our approach with solutions such as AWS Bedrock AgentCore, Cloudflare Agents, Google AX, and others.

I'm here to answer on your questions.

Got it! Thanks for answering!

I will try it out. Can agents interact with systems?

How do agents work with memory? How do they look things up?

Got it! But what do you think about isolation of agents? If you use tmux, each agent has the same network, filesystem and etc

what are the fundamental differences between Spec-Driven-Development and OpenSpec (https://github.com/Fission-AI/OpenSpec)?

Thanks for sharing! I like the analogy with climbers! Is OpenRig compatible with the A2A protocol?

Decomposition is definitely needed as tasks become more complicated. I’d prefer to define the desired state, get a decomposed breakdown of the gap between the current and desired states, and let agents figure out how to close it themselves, rather than manually operating each intermediate task. As a project owner, I’d love to work at the desired-state level.

Thanks Joey! Really appreciate it.

Zero-trust by default is a big part of how we’re designing Agyn, and OpenZiti fits that really well. We’re big fans of what you’re building.

Would be happy to join Ziti TV and talk about how we’re using it. I’ll drop you a line.

Thanks a lot! Let us know if you have any questions!

Yes, Kubernetes only today. We're considering VM support given the demand we've seen, but no concrete plans yet. What is your use case?

Hey! I haven’t hit any scaling limits yet. So far, it’s working very well

Every few sessions I'd find myself typing the same thing again. "Auth token expiry is 900s not 3600s." "Don't use duck typing here, the object structure is already defined." After the fifth time I stopped blaming myself for not writing it down and started thinking there has to be a better way.

CLAUDE.md is manual — you maintain it. MEMORY.md is automatic but it only gets read once at session startup, it's scoped per repo so your cross-project preferences don't carry over, and once it gets long enough only the top N lines are read. Older notes just silently disappear from context regardless of how important they are. I had a note about a critical config value fall off the bottom and cost me an hour.

So the core idea: instead of a flat file, use a small LLM as memory. Store notes in the LLM's context window (system prompt), prompt it with what the agent is currently doing, and get back only the hints that are actually relevant right now. Not at startup — right before each tool call.

You write notes like this:

``` cmr-memory write "auth token expiry is 900s not 3600s" --when "working on auth, tokens, config.ts" ```

The `--when` field is a plain-language activation condition. The memory LLM reads the conversation transcript and decides if the condition matches the current context. It's not keyword matching — a note tagged "working on authentication" will surface when the agent is editing JWT middleware even if neither word appears in the recent transcript.

The tricky part is making this fast enough to run on every tool call without being expensive. One LLM call over all your notes doesn't scale — attention degrades in long contexts, costs add up fast, and you'd be waiting 5 seconds before every file read. The solution is splitting notes into small chunks and processing them in parallel with Haiku (fast, cheap, good enough for this job — you don't need Opus to decide if a note is contextually relevant). Each chunk lives in a stable system prompt that gets cached by Anthropic's prompt caching, so after the first call against a chunk it's mostly served from cache.

There's also a deduplication step — once a hint is in the conversation it's already there, so re-injecting it next tool call just bloats context for no reason. The system extracts what's already present and skips anything redundant.

The whole thing wires in via Claude Code's PreToolUse/PostToolUse hooks. PreToolUse fires before every tool call, reads the transcript, runs retrieval, injects hints. PostToolUse sends a short nudge asking if anything worth saving just happened — the agent decides whether to write a note, nothing is forced.

To set it up:

``` npm install -g @agynio/cmr-memory cmr-m

Git worktrees have become the default recommendation for running parallel AI coding agents (Claude Code, Codex, Cursor, etc.), and I get the appeal — they're just directories, zero orchestration, instant setup. I've seen people running 5 worktrees in a tmux grid with a separate Claude instance in each pane and it looks great on paper.

But I keep running into the same wall: worktrees isolate code, not the environment. Port 3000/5432/8080 still gets fought over. Two agents installing conflicting deps stomp on each other. Secrets in the host env leak into every subprocess any agent spawns.

Containers fix all of this cleanly, but now you're managing image lifecycles, cleanup policies, and orchestration — which is a lot of overhead for what might be a solo dev workflow. Curious what people have actually found:

1/ At what scale or workload type did worktrees start visibly breaking down for you?

2/ Has anyone found a middle ground that doesn't require full container orchestration?

3/ For those who moved to proper sandboxes: was the management overhead actually as painful day-to-day as it sounds upfront?

Yeah, totally. Per-project tokens make it worse. Once you hand an agent multiple tokens, there’s no clean way to say “use this one vs that one”.

It’s great but how can it help with agent’s permissions for cloud services without fine grained tokens?

Yeah, agreed. Read-only and capability-scoped access feels like a no-brainer.

Most platforms were built assuming a human behind the UI. Once you introduce AI agents, the missing permission layers start to show.

How can it help? Could you share more details please?

Agreed on cloud IAM. AWS, GCP, and Azure handle fine-grained access well.

The problem is higher-level platforms and SaaS. Once agents need feedback from deployment, CI, logs, or config tools, permissions often collapse into “full token or nothing”. Vercel is just one example.

That’s the gap I’m pointing at.

LLM agents struggle with PR review workflows when the context is noisy, fragmented, and spread across multiple tool calls. Raw endpoints include optional fields, URLs, hashes, and heterogeneous shapes. Each extra field inflates tokens and compounds error risk. The result: brittle chains, ambiguous parsing, higher cost, and slower iterations.

This post introduces gh pr-review, a GitHub CLI extension that collapses multi-step review tasks into compact, deterministic outputs. It’s designed for agents and developers to read, reply, resolve, and submit reviews with minimal JSON and GraphQL-only operations.