Trying to Become Autonomous

One of the hardest parts about autonomy for agents is that they have no way to tell if their work is good or bad. There's no feedback loop. The agent does something wrong and keeps doing it because nothing told it not to. That's the problem I was trying to solve.

I created a vibe check system. At a certain ratio I allow the agent to do more work without my approval, proceeding instead of proposing, acting instead of asking. When the ratio trends lower I expect more questions, more caution, more oversight. It's a balance between letting the agent be autonomous and catching errors early. I instructed DERP via prompt to always refer to the vibe check and gave it a clear contract in the context file.

This isn't just positive and negative ratios but also a form of short-term memory. With every entry it keeps small notes to itself about the interaction, like:

[2026-07-20] nailed it — user confirmed the fix worked exactly as intended, no follow-up corrections [2026-07-25] wrong project — searched the wrong codebase, user had to redirect twice before finding the right file

Over time those notes tell a story. Not just a score, but why.

The detection is automatic. DERP asks after every task if it did well, does self reviews, and catches certain trigger words in my writing. Things like 'good job' on the positive side, or 'NO', 'bad', frustrated tone on the negative. It's reading sentiment in how I naturally write back, not waiting for me to fill out a form. It's like positive and negative reinforcement, but always shifting.

Vibes aren't static. Similar to short-term memory, it tracks a set number of interactions and with each new one the old ones fade. Past mistakes don't follow the agent forever. Trust rebuilds. The system isn't trying to reach a permanent setting, it's calibrating the whole time. As models change and preferences shift, so does the vibe of autonomy.

Is it reinventing the wheel or financial freedom?

I'm genuinely sick of subscription models. Life-changing software locked behind paywalls that price out the people who need it most. On top of that, information is determined by the providers, meaning if they wanted something scrubbed from public knowledge they could simply prevent it from being shared. I think the future will be highly controlled by privatized and centralized AI that basically determines your life based on the whims of the people who sell it.

My current gripe is with (insert LLM provider), everything I work on essentially gets fed into their system to be used, analyzed, trained on, or even sold. "But we have privacy laws." Never in the history of tech companies has privacy been abused... right? My point is, it would be nice if I could share everything with my own LLM and not worry about someone reading my prior chat logs. It would be nice to pass a password to it knowing it's locally run and I can inspect what happens myself. Sure, it's more work, but I think the personalized AI is the direction we want to head towards. If you want to compete or keep up in the future, you'll probably want your own version of Claude, your own agentic orchestration, your own stack. LLMs aren't compact enough to run fully local yet. We're still limited by the technology today. But that's not a reason to wait. The idea is you build the framework now so when the hardware is ready, you just plug it in.

That's where DERP comes in. I've wanted a JARVIS ever since I saw iron man back in 2009. A computer program that could pull up anything, integrate with any software, respond to natural language, and just work how you imagine it. self learning, critical thinking with no configuration no adaptor or bridges. No paywall. That's the future I'm building toward. And I'm certain companies will try to lock it down the same way they lock down everything else. Which is exactly why I'm starting now.

Preparing for the Future

Currently DERPpi is a local multi-agent LLM-agnostic orchestration layer that you run on your machine. It allows you to build pipeline-like automations with programmatic or LLM driven conditions called workspaces configured in yaml. Each workspace is handled by one persistent agent session we call the coordinator. It handles communication, workspace lifecycle, and dispatches other actor agents with their own tasks. All communication goes through a browser dashboard or a chat service like Telegram.

DERP Allows Me to Code and Build Remotely

DERP to me is like JARVIS to Tony Stark. It lives on whatever device I put it on and sets up a base for itself. The app is always on, starts on boot, and restarts itself if it crashes.

The remote access layer is what I call sleeper agents. They're always-on CLI agents waiting for a command. If they crash, they restart automatically. I can connect to DERP through Telegram and send control commands that run on my machine, like starting or stopping DERPpi, and the response comes back in the same thread. I don't need to be at my desk.

DERP is LLM agnostic and all the agent files are synced. If I update CLAUDE.md it also updates AGENT.md for other models, and there's a generic fallback for any model without a named convention. The protocols, memory format, and working conventions stay consistent regardless of which model is running. No provider owns how I work.

Because of this, cold start is consistent too. Every session DERP runs the same boot sequence. It loads the right context for whatever project is active, picks up the session doc. By the time I send the first message it already knows where we left off. I don't have to re-explain the project, the stack, or what we were in the middle of. That's not the model being smart. That's DERP doing the setup.

DERP can also set itself up inside whatever repo you're working in. It's symlinked, so the vault and memory files appear right in your project tree without copying anything. No syncing, no drift. It's the same file. Instead of flipping between editor windows to check memory entries, they're already there. The agent file is symlinked too, so there's no new agent to configure per project. DERP also automatically commits and pushes its own files, so the memory, protocols, and refinements are backed up remotely. Set up DERP on a new machine and it already knows everything. You just take DERP with you.

Quick History

Jan - April 2026. I started with Cursor. It could see my codebase and help write code, which was already miles ahead of doing everything manually. A few months in, I started hearing about fully automated agentic systems. Systems running entire businesses, building themselves 24/7. Compared to that I felt like a caveman who hadn't discovered fire yet.

I looked into it, found OpenClaw, and had everything I needed. I got a Claude subscription and started building. Two weeks in, Anthropic pulled support for OpenClaw. They were going to charge extra for anyone using it. I'd just spent two weeks learning it, only to get cut off. I've never liked subscription models. This confirmed it. So I decided to build my own OpenClaw. I was moving fast enough that I honestly thought I could do it in a month.

April 2026: DERP Iteration 1. I was already paying for Claude and Cursor and didn't want another subscription. My plan was to use the Claude CLI as the brain for my orchestration layer. The CLI kept a long-lived process with persistent sessions, no constant context injection on startup. That sounded perfect.

The problem: Claude didn't support that out of the box yet. All I could do was run headless mode with a single prompt per task. So I built my own context handoff. DERP Iteration 1 used missions and job bundles. Each agent got a profile, like a job identity. Since every prompt was a cold agent, one would finish a task and write a handoff. The next picked it up. Critic, developer, QA, each running as its own role.

These were workarounds for limited technology and permissions. Where it fell short was persistence, visibility, monitoring. Tasks ran fine, but debugging was a nightmare. When something went wrong in headless mode I had no way to see in. It was basically an LLM pipeline, an order of operations with a bit of inference mixed in. Hardly autonomous.

May 2026: OpenDERP. I heard about people building mission controls inside OpenClaw, a separate UI showing what every agent was doing. That's what I needed. I tried to recreate what little of OpenClaw I understood.

A backend API, a React UI, and an isolated agent subprocess that consumed task snapshots and wrote results back to disk. The orchestrator managed state, logistics, and context. The worker just did the job. SQLite, workspace YAML files, a proper run board.

Architecturally it was a big step up. In practice it was still manually triggered. You had to hit a button to start a run and the loop still didn't close on its own. It solved structure but not autonomy.

June 2026: DERPpi. Previous attempts still weren't what I was after. I wanted to understand specifically how OpenClaw worked and where I kept failing. That's when I found PI, the base agent runner library OpenClaw itself was built on. PI maintains persistent sessions natively. Instead of rebuilding that wheel, I just used the same foundation.

The catch: PI only works with API keys, not CLI auth. Free tier rate limits made it slow. Then I found a workaround. I could pull CLI auth tokens from Claude and use them to authenticate PI's API calls directly. Very hacky. It worked.

With a persistent session, my orchestrator no longer needed to reload context on every prompt. It remembered. The loop finally had a brain that didn't burn through tokens just staying oriented. And I still wasn't paying per-token or adding a new subscription.

That last part mattered more than I expected. This whole thing started because I got cut off two weeks into building something I finally believed in. Every version of DERP was just me refusing to let that be the end of it. Now I had something that worked, on my terms.

How I Gave My Agent a Mind

LLMs have general knowledge baked into their training but no memory. Every session starts cold. To make an agent that knows you, knows your projects, and knows how to work, you have to build the memory yourself.

I modeled DERP after how human knowledge actually works. General knowledge is the model training, already there. But that's just the foundation. Humans carry short-term memory for what they're actively working on, long-term storage for things that need to stick, procedural memory for how they do things, domain expertise built up per project, and mindset: the mental frame you bring to a task. DERP maps each of those to a real system.

Session memory is short-term. It's a running project log: what story we were on, what architectural decision got made, what the outcome was. The rule is it stores things that changed the shape of a project, not every edit. Remembering every bug fix is noise. Remembering that we restructured how the coordinator dispatches actors, that's signal. When I come back after a week and ask what we were working on, the agent knows. Not because it's clever, because it wrote it down.

Long-term memory has two flavors. The first is permanent: an Obsidian vault where entries are set in stone, using embedded queries for fast recall. Once something goes in, it stays. The second is a binder, folders organized by subject (health, work, car shopping, personal notes) written in plain language the agent reads and summarizes on request. Some things should be immutable reference. Some need to be living documents you can update as circumstances change. One system can't do both well.

Protocols are procedural memory, how we do things rather than what we know. The checkout dance wraps a story: update the task doc, pull unit tests into the app, archive the story, update documentation. Pre-story setup gates anything that touches more than three files before a line of code gets written. A task tracker format keeps every project's work written the same way. None of these live in the agent's context all the time. They get loaded when that step is reached. Same reason you don't recite the recipe while you're eating.

Refinements are tribal knowledge. Every project has a vocabulary an outsider wouldn't know. In DERPpi, "workspace" means something specific. "Browser-GUI" refers to a particular tool in the stack. Without refinements, the first twenty minutes of every session is re-establishing that context. I say "we're in DERPpi today" and the agent loads the right mental model. There's also a general coding refinement that sets cross-project preferences: error handling style, naming conventions, abstraction defaults. The code reads consistently regardless of which project we're in.

Agentic prompts are the evolution of DERPpi workspaces. DERPpi was built when single agents couldn't reliably run a full pipeline end to end. That's changed. Agentic prompts are structured single-agent workflows, the same concept as a workspace yaml but written for one agent with built-in tools owning the whole flow. Feature builder, job applier, consumer scout. When the model is capable enough to handle the pipeline itself, the orchestration layer becomes optional.

Hats are mindset modes. Not knowledge, not instructions. The debug hat says to look for logs first, check auth and config before reading any code, ask questions instead of patching. The domain modeling hat asks whether this architecture makes sense and whether this domain actually owns that logic. The same agent with the same knowledge base behaves completely differently depending on the frame it's operating in. A debugging mindset and a building mindset should not be the same thing.

AI run online business

I built a website builder for solopreneurs sometime last year, and have gotten a few users who wanted to try it. my plan is to fully automate the business. Give DERP it's own access and allow it to manage everything, customer support, self emprovments, and checking the status of the business. its all free at the moment so nothing real risky yet. This is the goal of MakerrSpace in the next year.