There are things we’ve been doing for years as programmers. But let’s pretend most of it does not matter anymore, and see what lies in front of us today.
#Ownership
We take full responsibility for our work. With that in mind, handing ownership over to language models doesn’t seem reasonable. Confabulation (Why Language Models Hallucinate) and prompt injection are two good reasons why. Both pose serious security risks and remain open problems. After all, who wants an agent with access to a production database that can drop it along with all the backups in seconds?
At the same time, there’s no denying that AI agents can bring a lot of value. They can do in days what would normally take us years, and this isn’t the only case.
But does giving agents more responsibility and access while reducing oversight mean we also need to give them ownership? Not necessarily. But the question is: how?
#Primitives
Let’s say we’re building a product and use an issue tracking system to manage ideas, feature requests, and bug reports. These issues are often created manually based on input from internal meetings, the support team, social media, analytics tools, or production server logs.
Most issues can be handled through the normal workflow, but some require immediate action. In those cases, we often set up a notification that triggers a “red alert” even at 3 a.m. If we’re unlucky, no one responds until morning, leaving some users unhappy.
Coding agents can access external services through the CLI and MCP. But no one wants to keep asking them to scan support tickets, emails, or chat messages just to add a few entries to the issue tracker. Automating the process makes much more sense. The problem is that every run takes time and costs money. Add a few automations like this, and your token bill can quickly skyrocket, or you may burn through your subscription limits in a single day.
But nobody said that the agent has to perform the entire work each time. Instead it could create a dynamic package with the logic that will be deterministically invoked, passing to the model the exact data it needs.
The Package is the first primitive here. Its source is a git repo in Cloudflare Artifacts, and the built bundle sits in Workers KV.
A one-off script usually isn't enough because it needs to remember things, so every package gets a Durable Object with its own SQLite database. Nothing gets deployed. A Worker loads the bundle and runs it in a sandbox with no access to anything else.
The difference is visible after the first run. Compared with a typical agent using MCP or CLI tools, an agent that uses primitives like Packages makes subsequent runs more reliable, faster, and cheaper.
Below, two agents aim to solve an issue that requires access to a list of payments. The first agent retrieves the payments manually each time, while the second writes a script to filter them deterministically.
Conclusion: Agent capabilities are changing not only how we create software, but also what software can do. In many cases, this requires a shift from building features to shaping environments where agents can manage their own capabilities.
#Autonomy
Making agents faster and more reliable improves efficiency, but only to a point, as human involvement soon limits further progress. One approach is to restructure the system so that humans work with "manager" agents that coordinate subagents or workers. Alternatively, humans can be removed from the process entirely—or almost entirely.
The questions are how to achieve this, how to make it reliable, and how to keep it secure.
First, the agent almost always needs to run in the cloud—whether it’s Cursor Cloud Agent, Codex Cloud, Grok Bot, or a custom Pi setup hosted on your VPS. That keeps it available to interfaces such as T3 Code UI and, more importantly, running while your computer is offline.
The easiest way to get started with remote agents is to use Cursor or Codex. Running them on your own VPS requires more setup and comes with additional costs, including the VPS itself and tools like Tailscale. You may also want to use Pi, Herdr, or Moshi.
Always-on agents aren’t enough if they still require constant supervision. To improve their autonomy, we need to give them well-organized, accessible context, including:
- General context: short files that include the project vision and a map of the most important knowledge sources: documentation, specifications, and so on.
- Specifications: a self-managed list of planned, active, and completed features to track progress, coordinate multiple agents, and understand historical changes beyond code.
- Environment: MCP and CLI access to GitHub, issue trackers, monitoring, communication tools, server logs, the browser, and even the entire desktop.
- Communication: Agents need to be able to reach us easily when necessary, while external systems must also be able to reach them.
Below is a visualization of an agent that automatically picks up support requests, gathers context, manages its own work, connects to the browser and server logs, and collects evidence. It then resolves the issue and opens a pull request for a human or other agents to review.
When working with background agents, keep in mind that they can make mistakes and can be tricked into taking unwanted actions. At a minimum:
- Do not give them unsupervised access to production servers.
- Minimize their exposure to prompts from untrusted sources, such as support tickets.
- Restrict their access to nonessential tools, especially those that could lead to data leaks or similar risks.
- Provide only anonymized data while preserving enough context for them to solve the issue.
- Limit the number of requests they can receive to prevent spam and misuse.
#Workflows
Now that we can generate code easily, it’s worth using this capability not only for our day-to-day work but also to build tools that improve our workflows and agents.
For example:
- Pi extensions can personalize agents for each project or workspace.
- Pi extensions can manage herdr workspaces and settings.
- Agents can spawn other agents—even those running in different harnesses, allowing you to combine tools like Claude Code, Codex, and Grok.
- Agents can build a shared library of reusable scripts for multimodal processing, artifact management, uploads, and general knowledge about you.
- Background agents can review your Superwhisper history or threads from your coding harness, extract reusable skills, review code, and suggest improvements.
- Agents can help keep documentation up to date, especially when it’s Markdown-based and built with tools like Astro or Next.js.
- Agents can monitor communication channels, help shape issues for upcoming sprints, prepare you for meetings, and assist with work reporting.
- With remote agents and self-organizing specs, you can work with agents through mobile interfaces such as Moshi, T3 Code, or Codex.
In other words, we can now build a system that works for us. Most of its modules can be set up with zero-shot prompts to the agent. The key is not to overengineer it and to give the main agent enough control, so we don’t spend more time managing the system than benefiting from it.
Below is a high-level overview of such a system, with the right context, tools, integrations, autonomy, and a well-designed interface that keeps us in the loop.
In practice, it’s a good idea to avoid becoming attached to specific tools and keep the setup tool-agnostic. Whenever possible, it’s also better to use tools built by others than to create everything from scratch, even if "code is free". The same goes for frameworks, libraries, CLIs, MCPs, and so on.
Recommended tooling:
- Harness: Pi, Omp, DeepSeek AI, Cursor, Codex
- Terminal: Cmux together with Herdr
- UI: T3 Code, Superset
- Mobile: Moshi (together with Tailscale)
- CLI: agent-browser, chrome-devtools-mcp
- VPS: DigitalOcean or Hetzner
