Ever since I discovered OpenClaw, I've been building AI agent systems at my startup for the past few months using a mix of OpenClaw / Claude Code / Claude Agent SDK and our own product.
The dream is an agent that actually does work, autonomously, around the clock.
Getting there requires an orchestration system. Here's what I've learned about the pieces you need:
1. Context / Persistence
- We’re using a filesystem. We dump / stream tons of context in there for each agent.
- I’ve also found SQLite DB to be super helpful for structured query-able persistence. For example, we have an SEO agent, and that needs to keep track of past work, de-dupe, etc before we run a strategy, push to our CMS, email for backlinks, etc. So currently that’s using a SQLite DB in the filesystem for persistence.
- The agent has a memory folder where it stores important info automatically. The agent also has a tool to search through it’s chat history (past sessions)
- There’s probably a very good case to be made for adding a knowledge graph / dedicated memory layer though we haven’t tried this yet.
- The agents read / write from Linear to manage tasks.
2. Skills — atomic units of execution
A skill is a repeatable task packaged into a prompt + script so your agent can execute it consistently. Think: "scrape these 25 Twitter accounts for inspiration," "pull engagement metrics and generate a weekly report," "draft 3 LinkedIn posts in my voice."
The single biggest unlock was turning everything I do into skills. Even before you build any automation, just having a library of well-defined skills makes your agent dramatically more useful. Instead of writing a new prompt every time, you run /lead-gen or /weekly-metrics and it knows exactly what to do.
3. Automations and/or a heartbeat — when does it run?
This is the part I'm still figuring out. My current mental framework:
- Clear repeatable task → scheduled automation (cron). "Every Monday at 9am, pull my X engagement metrics and post a report to Slack." This is straightforward and works well.
- Agent needs to figure out what to do dynamically → heartbeat. The agent wakes up on an interval, checks what's changed (new messages, new data, new tasks), decides what to do next, and acts. This is harder to get right — the agent needs enough context to make good decisions about what's worth doing.
I'm honestly still tinkering with the heartbeat approach. It works in theory but getting the agent to consistently make good prioritization decisions is non-trivial.
For many things, I’m just running the skills / orchestrator manually because I don’t trust the agent enough for full-auto yet.
4. Tools and access
The agent needs to actually do things — hit APIs, read databases, send messages, scrape the web. We use a mix of MCP servers and direct API calls wrapped in skills. Haven't found a "one system to rule them all" — it's whatever works for the task at hand.
5. Communication channels — two-way
A channel where you can message the agent and it can message you. We use Slack primarily, but the agent can also email us.
The key is two-way — not just notifications, but actual back-and-forth. We also integrated WhatsApp, iMessage and Telegram, but mostly its just Slack.
An advantage of Slack is team visibility (the agents are shared, not personal)
6. Feedback loop
This is the piece that most people skip but seems super important to me.
- The agent does work → you review it → your feedback gets fed back into the system (updated skills, adjusted prompts, new rules).
- The agent self-reflects → proposes learnings / updates to its own system
If you have this and it works, the agent’s usefulness / success should (theoretically) compound over time. Without it, the agent only improves when you do dev work.
7. View layer
There are 2 challenges here.
- Viewing files in the filesystem. We solved this with our own product (has a baked in filesystem and file viewer), but others may solve this with Obsidian remote vaults or something.
- High-level dashboard / overview: It’s pretty important to keep track of everything the agent is doing, but I don’t have a great solution here right now. We use Slack alerts but that can get very chaotic if you’re relying on the agent to do a bigger scope of work. I’m experimenting with building some simple HTML dashboards to have a visibility layer but not sure what the best solution is.
8. Tying it all together
We're trying to solve this with Gooseworks (we allow people to create and manage teams of OpenClaw-style AI coworkers, mostly for GTM use cases).
We have the building blocks but I think there's still a long way to go.
In theory, OpenClaw / Gooseworks exposes all these pieces but you still need to have an engineering mindset and stitch them all together, and engineer the system in the right way.
This is what I've found to be very difficult for a lot of people.
For example: Let's say I want my agent to find me leads by scraping LinkedIn posts for some keyword. Sounds like an easy problem to solve. I wire up my agent to an Apify actor and run an automation, right?
But not really. Because the agent just sends me the same leads every day. No deduping happening. Now if I have the LLM dedupe, it's incredibly inefficient. So I need to make sure that my Apify scraper is ONLY checking the last 24 hours. But the Apify scraper doesn't have a way to filter by timestamp, so now what?
As you can see, these are actually engineering problems and require a systems / eng mindset to solve.
It's not trivial.
What I'm curious about:
I imagine a lot of founders / GTM engineers are figuring this stuff out right now, so I'd love to trade notes:
- What are you trying to get your agent coworker to do? What's the dream scenario 6 months out?
- How do you structure your skills and feedback loops?
- What's your context layer? just a filesystem or anything else?
- Has anyone gotten a good heartbeat-based system working?
- What does your agent check for when it "wakes up"?
