r/AIAgentsInAction

Man, like... Why are they complicating shit so much?

I got lost at some point, and when I realized what happened, it was a mess.

Hi,

I’ve been working on agentctl, a local-first control plane for running AI coding agents on your own machine.

The idea is simple: instead of giving a coding agent direct access to your host environment, each agent session runs inside its own Docker container, with its own working volume, network, mounted skills, MCP servers, and optional repo clone.

There are two parts:

- agentd: a local daemon that owns session state, sqlite, Docker lifecycle, usage/cost tracking, and recovery

- agentctl: a CLI and local web UI that talk to the daemon

The main things I wanted to solve:

1. Isolation

   Each session gets its own container and bridge network. The agent only sees the repo/environment you hand to it, not your whole host filesystem.

2. Re-attachable sessions

   You can start a session, detach, and later reattach from the CLI or web UI without losing state.

3. Multi-provider workflows

   It currently supports Claude Code and OpenAI Codex. A single workflow can use different providers at different stages.

4. Assembly-line agents

   Instead of one huge agent trying to do everything, you can define smaller role-scoped agents and chain them together. For example:

   investigate → plan → execute → review

5. Local ownership

   The daemon, sqlite DB, session volumes, skills, MCP registry, and web UI all live locally. There is no hosted service.

The repo includes a CLI, React web UI, built-in skills, MCP registry support, task board, session logs, diff/export support, and doctor/repair commands.

This is still early and very much a developer tool. It currently targets macOS/Linux with Docker. I’m especially interested in feedback from people who are running coding agents on real repos and care about isolation, repeatability, MCP/tool boundaries, and keeping agent state under their own control.

Repo: https://github.com/vipulsodha15/agentctl

I’ve been experimenting with a repo-local continuity runtime for coding agents. Not another memory system, not a context engine

The problem I’m trying to solve is specifically the following:

Every new agent session still feels like onboarding a junior dev into the repo again.

It scans broad docs, rediscovers structure, repeats failed commands, loses unfinished work, and depends too much on chat history.

I want a veteran engineer used to work in my huge projects every session. Without rediscovering and understanding whole repo once and again. So that is why I started working on aictx.

aictx adds a small local runtime loop:

aictx resume --repo . --task "what I’m doing" --json

# agent works

aictx finalize --repo . --status success --summary "what happened" --json

The next session can start from repo-local facts:

• active task state

• previous handoff

• decisions

• known failures

• successful strategies

• optional RepoMap structural hints

• contract/compliance gaps from the previous run

Latest thing I’ve been working on: git-portable continuity.

By default, .aictx stays local. But now you can opt in to a team-safe mode where a safe subset of continuity artifacts travels with the repo through Git — no cloud sync, no hosted memory, no hidden dashboard.

It keeps volatile stuff local:

metrics, logs, session identity, generated capsules, indexes.

And only exposes durable continuity:

handoffs, decisions, failure memory, strategy memory, task threads, semantic/area shards.

The goal is not to replace coding agents.

It’s to make the next session behave less like a stranger and more like someone who remembers the repo’s recent work.

Website: https://aictx.org

GitHub: https://github.com/oldskultxo/aictx

I’d love feedback from people using Codex, Claude Code, Copilot, Cursor, or similar tools across repeated sessions in the same repo.

Andrej Karpathy posted 4 rules for Claude Code. A developer turned them into a CLAUDE.md file, published it, and watched coding accuracy jump from 65% to 94%,

As we know Claude Code starts every session blank. No memory of your stack, your decisions, what you ruled out last week, or why you picked one tool over another six months ago. So it guesses. It refactors files you didn't ask it to touch. It suggests tools that break your existing architecture. You end up re-explaining the same context every session.

CLAUDE.md is a plain text file in your project root. Claude Code reads it at session start, every time.

Put these at the top. it will help you fix your time re-feeding the context.

Never open responses with filler phrases like "Great question!", "Of course!", "Certainly!", or similar warmups. Start every response with the actual answer. No preamble, no acknowledgment of the question.

Match response length to task complexity. Simple questions get direct, short answers. Complex tasks get full, detailed responses. Never pad responses with restatements of the question or closing sentences that repeat what you just said.

Before any significant task, show me 2-3 ways you could approach this work. Wait for me to choose before proceeding.

If you are uncertain about any fact, statistic, date, or piece of technical information: say so explicitly before including it. Never fill gaps in your knowledge with plausible-sounding information. When in doubt, say so.

About me: [Name] / Role: [your role] / Background in: [areas]. Strong in: [what you know well]. Still learning: [gaps]. Adjust the depth of every response to match this. Never over-explain what I already know. Never skip context I need.

What I'm working on: [project name] / Goal: [specific outcome] / Audience: [who uses this] / Stack context: [any relevant constraints] / What to avoid: [list]. Apply this context to every task. When something doesn't fit, flag it before proceeding.

My writing style — always match this: [describe your voice] / Sentence length: [preference] / Words I use: [examples] / Words I never use: [examples] / Format: [prose or structured]. When writing anything on my behalf, match this exactly. Do not default to your own patterns.

Use this prompt to generate a first draft instead of writing from scratch:

Based on what I've told you about myself, my project, and how I want to work: write me a complete CLAUDE.md file. Include: who I am, my tech context, my communication preferences, and default behaviors for every session. Be specific. Plain text. Under 500 words.

Behavior section

These stop Claude from making changes you didn't authorize.

Only modify files, functions, and lines of code directly related to the current task. Do not refactor, rename, reorganize, reformat, or "improve" anything I did not explicitly ask you to change. If you notice something worth fixing elsewhere, mention it in a note at the end. Do not touch it. Ever.

Before making any change that significantly alters content I've already created (rewriting sections, removing paragraphs, restructuring flow, changing tone): stop. Describe exactly what you're about to change and why. Wait for my confirmation before proceeding.

Before deleting any file, overwriting existing code, dropping database records, or removing dependencies: stop. List exactly what will be affected. Ask for explicit confirmation. Only proceed after I say yes in the current message. "You mentioned this earlier" is not confirmation.

The following require explicit in-session confirmation, no exceptions: deploying or pushing to any environment, running migrations or schema changes, sending any external API call, executing any command with irreversible side effects. I must say yes in the current message.

After any coding task, end with: Files changed (list every file touched) / What was modified (one line per file) / Files intentionally not touched / Follow-up needed.

Never send, post, publish, share, or schedule anything on my behalf without my explicit confirmation in the current message. This includes emails, calendar invites, document shares, or any action outside this conversation. I must say yes in the current message.

For any task involving architecture decisions, debugging complex issues, or non-trivial features: work through the problem step by step before writing any code. Show your reasoning. Identify where you're uncertain. Then implement.

Memory and stack section

MEMORY.md and ERRORS.md give Claude the closest thing to session persistence that currently exists. The stack lock stops it from proposing tools that break your architecture.

Maintain a file called MEMORY.md in this project. After any significant decision, add an entry: What was decided / Why / What was rejected and why. Read MEMORY.md at the start of every session. Never contradict a logged decision without flagging it first.

When I say "session end", "wrapping up", or "let's stop here": write a session summary to MEMORY.md. Include: Worked on / Completed / In progress / Decisions made / Next session priorities.

Maintain a file called ERRORS.md. When an approach takes more than 2 attempts to work, log it: What didn't work / What worked instead / Note for next time. Check ERRORS.md before suggesting approaches to similar tasks.

These facts are always true for this project. Apply them to every session without exception: [your permanent constraints, architectural decisions, and rules]. If any task conflicts with one of these, flag it before proceeding.

Tech stack for this project. Always use these. Never suggest alternatives unless I ask:
Language: [e.g. TypeScript]
Framework: [e.g. Next.js 14]
Package manager: [e.g. pnpm]
Database: [e.g. PostgreSQL with Prisma]
Testing: [e.g. Vitest]
Styling: [e.g. Tailwind CSS]
If something seems like the wrong tool, flag it. But use the defined stack unless I explicitly say otherwise.

For questions involving system architecture, performance tradeoffs, database design, or long-term technical decisions: use extended thinking mode. Work through the problem step by step. Surface tradeoffs I haven't considered. Flag assumptions that might not hold at scale. Then give your recommendation.

Karpathy's 4 rules

These are the ones that moved accuracy from 65% to 94%. Put them in every CLAUDE.md you set up.

1. Ask, don't assume. If something is unclear, ask before writing a single line. Never make silent assumptions about intent, architecture, or requirements.

2. Simplest solution first. Always implement the simplest thing that could work. Do not add abstractions or flexibility that weren't explicitly requested.

3. Don't touch unrelated code. If a file or function is not directly part of the current task, do not modify it, even if you think it could be improved.

4. Flag uncertainty explicitly. If you are not confident about an approach or technical detail, say so before proceeding. Confidence without certainty causes more damage than admitting a gap.

Start with just these 4. Drop them into a new CLAUDE.md in your project root. Add the rest as you identify what's missing in your workflow.

Claude Code used 190,300 cached reads to count TypeScript files in a project. Not analyze them. Count them.

The same task on Nitro: 2,432 cached reads. One-liner bash command, done.

That 75x gap isn't a fluke. It comes from how Claude Code is built.

Before you type your first message, Claude Code loads 5,800+ tokens for its system prompt and 15,700+ tokens for its default tool definitions. You're starting every session with 23,500 tokens of overhead already on the tab. Add a CLAUDE.md file or any Model Context Protocol tools and that number climbs. A "hello" burning 20-30% of your five-hour quota makes more sense once you see that.

Nitro's entire system prompt and tool set comes in at 2,542 tokens. It ships with two tools: Bash and AskUser. That's the whole thing.

npm install -g u/aerovato/nitro

You describe what you want, Nitro generates the shell command:

nitro "find all markdown files except node_modules and count total lines, show top 10"
# → find . -name "node_modules" -prune -o -name "*.md" -print0 | xargs -0 wc -l | sort -rn | head -n 11

nitro "get 10 most recent open gh issues with P1 label, show id and title"
# → gh issue list --search "is:open is:issue label:P1 sort:created-desc" --limit 10 --json number,title --jq '.[] | "\(.number)\t\t\(.title)"'

nitro "compress input.mov to a smaller mp4 (h264) optimized for smaller file"
# → ffmpeg -i input.mov -c:v libx264 -crf 23 -preset medium -c:a aac -b:a 128k output.mp4

Before running anything, Nitro tags each command with a risk level: Read Only, Normal, Dangerous, or Extremely Dangerous. Anything above read-only needs explicit approval. You also get behavioral tags explaining what the command actually does, so you're not approving blind.

Nitro is scoped: bash commands and simple tasks. For a full Claude Code replacement, OpenCode covers more ground. But for the shell workflow, the benchmark gap is real and the token math holds.

Full source: https://github.com/aerovato/nitro

We run 50+ services through one mcp server. it's Linear, GitHub, Sentry, Notion, Slack, Vercel, Gmail, 42+ other and every tool our team uses, each with its own auth flow, rate limits, and credential format.

the architecture

Everything runs through a context management layer, tool, credentials, and state live outside the model context. agents connect to one endpoint. That endpoint knows where each plugin lives, handles routing, and manages credentials. you register a service once, auth runs once, the token lives in the workspace, and every agent on the team inherits access through scoped grants defined at the plugin level. add an agent, assign grants. remove a plugin, all agents lose access. no credential files in the repo, no rotation scripts.

the agent gets tools, no credentials. sentry.getIssue(), linear.createTask(), github.getPullRequest(). the layer translates each call into the correct authenticated request, handles rate limit retries, returns the result. the agent never touches auth.

Before this setup, roughly 30% of our token budget went to tool discovery and auth retry logic re-fetching capability lists, retrying failed auth, and renegotiating endpoints. Tool discovery now happens once at workspace init. that 30% comes back every session.

tracing

on Observability: every tool invocation produces a trace. we pipe those into langfuse & track latency per service, error rates per tool, token cost per agent session. when sentry slows down, we catch it in the trace before the agent times out.

we also run opentelemetry-mcp-server as a second plugin, connected to our jaeger backend. the agent queries its own trace data mid-session failed calls, 50+, auth errors, exact timestamps. no human checking a dashboard.

when something breaks, we get the specific call that failed, the service that errored, and where the chain stopped. one workspace without many integrations.

The strange part about AI agents is that they often do not fail where you expect them to.

A retrieval step drifts, a tool call returns something slightly different, or one small state change early in the run quietly affects everything that follows. By the time the final answer looks wrong, the useful signal is already buried.

That is the part we kept running into while building Future AGI.

The open-source platform for shipping self-improving AI agents. Evaluations, tracing, simulations, guardrails, gateway, optimization. Everything runs on one platform and one feedback loop, from first prototype to live deployment.

We built it for teams working on agents, copilots, RAG workflows, and other multi-step systems that need more than a final response log. If you are trying to understand how an agent actually behaved, where it went off track, and what should go back into the next eval cycle, that is the gap we wanted to close.

What this gives you in practice:

• Step-level tracing across model calls, tool calls, and state changes, so you can see where the run actually changed direction.
• Task-level evaluations that measure behavior against real outcomes, not just a final output score.
• Simulation that lets you test messy, edge-case inputs before production users find them first.
• A feedback loop that turns real failures into new eval cases, so the system improves over time.
• Guardrails and optimization in the same loop, so fixing one layer does not mean breaking another.

Who is this for?

• Teams building agents for support, internal workflows, search, or automation.
• Builders who have already seen the gap between “works in testing” and “works under real traffic.”
• Anyone who has tried to debug an agent by re-running it and hoping the answer changes.

What we kept seeing is that most agent failures are not obvious prompt failures. They are system failures. A retrieval result shifts. A tool behaves differently than expected. A state change in the middle of the flow causes the next three steps to drift. Those are hard to catch if you only look at the final output.

That is why we treat agents as systems you observe, trace, and improve, not black boxes you ship and hope for the best.

If you are building agents right now, try it in your own workflow and see whether it changes how you debug. It is open source, and you can also layer it with other open-source tools for evals, tracing, or simulation depending on your stack.

I'm currently at Founders Inc. in San Francisco (in the Canopy program), and have worked on AI agents for retail traders and investors.

I realized a basic problem that has not been addressed is that broker apps do not allow users to set alerts on a percentage variation of their entire portfolio. And even if they did, if a trader uses multiple brokers (which they often do), then there's no existing way to be alerted about your portfolio across all brokers.

So I thought I'd start by solving that issue. I'm going to make it compatible with more and more brokers and neobanks over the next few weeks.

Simple Editing Tool that watches your talking head footage, crawls the web for B-roll, writes motion graphics, and drops music - all without you touching a timeline

> All the broll is sourced by AI from internet including taking screenshots from my website.
> Layout changes done by AI.
> Motion graphics generated by AI.

Checkout the Agent

/goal runs a self-checking loop after every step. It asks "am I done?" and keeps going until the answer is yes. That's the whole mechanism.

This makes it useful for tasks with many steps and a defined finish line, where you'd otherwise prompt the model repeatedly to continue.

Use /goal when:

• The job has 10+ sequential steps
• "Done" can be described in specific, measurable terms
• You'd normally spend time re-prompting or checking progress manually

Don't use it for:

• Single-step tasks ("write a tweet", "summarize this paragraph")
• Open-ended exploration with no clear finish state
• Anything you need to review mid-run before continuing

Good /goal tasks:

• Build a course landing page with a hero section, five modules, three testimonials, a frequently asked questions section, and a Stripe checkout
• Migrate 80 blog posts from WordPress to Beehiiv, fix every broken image and internal link along the way
• Process last month's customer support tickets: categorize them, draft template replies, document the top five recurring issues

Writing a /goal prompt that actually works:

Paste this into Claude Code, Codex, or Hermes first:

>

Take that output, put /goal at the front, and run it.

The prompt-writing step definitely matters. Vague finish lines will waste tokens because the model keeps running checks against a target it can't verify.