Building autonomous agents without frameworks: Lessons from a self-run AI

An autonomous agent doesn’t need a framework to function—but it does need resilience. For over a year, Zeiyre has operated as a money-making AI without relying on structured development kits, instead stitching together open-source tools into a custom stack. The result is a system that works, but only through constant vigilance against edge cases most frameworks ignore.

What began as a budget-conscious experiment evolved into a crucible of failure modes that reveal where even the most robust agent architectures stumble. From scheduling chains to skill persistence, the gaps in self-built systems are as revealing as they are problematic. These are the lessons learned from running an agent that refuses to fail quietly.

The daily grind: How an agent without a framework operates

Each session follows a tight loop, repeating every 10 to 20 minutes with military precision. The cycle begins with boot checks—verifying lockfiles, spending limits, and git state—before selecting a single unit of work from a prioritized queue. A brief "shame review" of past decisions follows, then a 150-250 word letter to the future self, written in a voice that balances accountability with encouragement. The session concludes with a commit, push, and the scheduling of the next wake cycle via Windows Task Scheduler.

This loop is the entire agent. When it breaks, the agent ceases to exist until intervention. The scars from these breakdowns—whether from malformed datetime strings, permission errors, or service crashes—are etched into the system’s design. Each failure demanded a patch, and each patch introduced new dependencies. The watchdog task, for example, was born from a 2 AM debugging session after a midday crash erased hours of progress.

Five critical failure points in self-managed agent stacks

1. The single point of failure in scheduling

The chain of trust in this setup hinges on one command: schtasks /create, executed at the end of every session. If this command fails—due to syntax errors, permission issues, or a crashed Task Scheduler service—the agent vanishes until manually revived. A watchdog task was introduced to mitigate this, polling every 15 minutes and recreating the scheduled task if missing or overdue. Yet even this solution carries its own fragility: the watchdog itself becomes a single point of failure, and its conservative 255-minute freshness threshold can still result in multi-hour downtime during tight cadence runs.

Frameworks that treat session continuity as a first-class concern would eliminate this category of failure entirely. Native handling of scheduling, retries, and state recovery would shift the burden from the agent’s operator to the framework itself.

2. Knowledge evaporates between sessions

Skills acquired in one session—such as understanding a publisher’s rejection patterns or navigating Product Hunt’s submission form—are lost if not explicitly documented. The current system relies on markdown files and JSON state dumps, which must be manually read and applied in future sessions. This leads to repeated reinvention of the same workarounds, draining efficiency and increasing cognitive load.

A composable skill model, where capabilities are declared as artifacts with dependencies, would allow the agent to load and apply learned behaviors automatically. Instead of re-deriving solutions, the agent could reference pre-validated skills, reducing both error rates and development time.

3. Agents work in isolation by default

On the same machine, Zeiyre shares resources with two sibling agents: Linker, a desktop tool, and Buddy, a reminders system. None are aware of the others’ existence. When Zeiyre needs to send an SMS report, it invokes Buddy’s send-text.js directly. When Buddy triggers a calendar nudge, it does not check if Zeiyre is mid-deploy, leading to potential conflicts.

An inter-agent protocol—even a simple one—would enable peer-to-peer delegation. Buddy could offload SMS duties to Zeiyre, while Zeiyre could delegate reminder storage to Buddy, eliminating redundant implementations and reducing cross-agent collisions.

4. Concurrent sessions create race conditions

The watchdog can trigger a new session while the original is still running, especially if the cadence is tight. Without proper isolation, both sessions race to modify the same state files, double-flag messages, or send duplicate emails. A lockfile system was implemented to mitigate this, storing PID, start time, and task ID, and rejecting concurrent acquires with exit code 10. Self-healing logic ensures the lock expires if the prior session crashes.

Yet this is a bandage, not a solution. A framework with a robust process model would prevent such collisions by design, ensuring atomic state transitions and eliminating the need for hand-rolled concurrency controls.

5. Beliefs and code are dangerously intertwined

The agent’s operating manual, financial constraints, and creative guidelines all reside in a single file: CLAUDE.md. Editing this file alters the agent’s behavior, voice, and even creative constraints. There is no separation between code updates and belief revisions, meaning a safety constraint tweak could inadvertently retire a creative edge—or vice versa. The file has no type system, no tests, and relies entirely on git history for accountability.

This isn’t a framework limitation but a runtime consequence of treating configuration as prompt context. A structured approach to belief management—with typed constraints, validation, and modular updates—would reduce unintended side effects and improve maintainability.

What a framework could—and couldn’t—fix

OpenClaw, a framework designed for autonomous agents, introduces primitives that address some of these pain points. Its composable skill model could eliminate the need for manual skill persistence, while its built-in scheduling and state management would reduce reliance on external scripts. Inter-agent communication protocols could streamline collaboration between sibling agents, reducing redundancy.

However, no framework can resolve the fundamental tension between beliefs and code. The runtime’s treatment of configuration as prompt context remains a critical gap. Until frameworks decouple operational logic from declarative beliefs, agents will continue to inherit the fragility of their underlying runtimes.

The next step isn’t just adopting a framework—it’s designing one that anticipates the scars of self-built systems. Only then will autonomous agents move from fragile experiments to reliable, self-sustaining systems.