14 OpenClaw Practices From 200 Hours of Heavy Use

The most common response to a disappointing AI agent is to upgrade the model. It is also almost always the wrong move. After 200 hours and billions of tokens working with agentic systems, the clearest finding is this: the agents that hold up in daily business use do not hold up because of which model runs under the hood. They hold up because of how they are structured, and the agents that fail almost always fail for structural reasons that a more powerful model cannot fix. Madhuranjan Kumar has seen this pattern repeat across dozens of setups, and the fix is never what people expect.

The memory complaint is almost always a threading problem

When an AI agent starts forgetting things, the immediate reaction is to assume the model's memory is weak or the context window is too small. Both diagnoses lead to the same prescription: try a stronger model. Both are usually wrong.

In most real deployments, the forgetting happens because everything is running in one long conversation. A single continuous session interleaves scheduling questions with customer records with operational notes with draft communications, and the model has to hold all of it simultaneously. As the conversation grows, older context gets pushed toward the edge of the window, and the agent starts behaving as though it does not remember things from early in the session.

The fix is threading: separate conversations for separate topics. Create one thread for scheduling and dispatch, another for customer records, another for draft communications, another for supplier questions, and a housekeeping thread for overnight maintenance. Each thread keeps its own focused context. When you open the scheduling thread, the agent loads only scheduling context. When you open the customer records thread, it loads only customer context. The interleaving problem disappears because the topics never share a session in the first place.

Switching from one long session to properly threaded conversations typically resolves 80 percent of what business owners describe as memory problems, with no model change required. The model was not forgetting. The structure was making it appear to forget. The upgrade purchase would have done nothing.

Prompt design is model-specific, and treating it as universal costs you 20 percent of your results

Most businesses that deploy multiple AI models use the same system prompt for all of them. It feels efficient. One prompt to write, one prompt to maintain. The cost is real and measurable: different models have genuinely different preferences for how instructions should be written, and ignoring those preferences produces consistently lower-quality outputs.

Some models respond poorly to all-caps instructions and negative framing. Others are trained on data that rewards explicit, direct commands with numbered steps. Some handle long contextual system prompts well. Others perform better with compact, declarative prompts that state facts and rules without explanation. Using a prompt written for one model's preferences with a different model is not neutral. It actively works against that model's strengths.

The solution is a separate prompt file per model, written to match each provider's documented prompting best practices. When a new model is added, download its provider's prompting guide, feed the current prompt along with the guide to the agent, and ask it to rewrite the prompt to match the new model's preferences. The quality improvement is visible immediately on side-by-side comparison. The maintenance cost is modest: update each prompt file when a model changes significantly, which happens a few times a year at most. For a business running high volumes of agent interactions, the cumulative quality difference across thousands of transactions is significant.

Cheap model routing beats running a powerful model on everything

Running a single frontier model for all tasks in an agentic system is not just expensive. It is often counterproductive. Frontier models are optimized for complex reasoning, nuance, and multi-step synthesis. Routing simple, repetitive tasks through them is like hiring a specialist for work that a generalist handles just as well at a fraction of the cost.

The better approach is explicit model routing: map each category of task to the cheapest model that handles it cleanly. A capable but inexpensive model handles customer inquiry drafts, appointment confirmations, and simple data lookups. A stronger model handles complex multi-part quotes, nuanced customer situations, or planning tasks that require weighing several factors. A small, fast local model handles classification tasks: is this message a scheduling request, a complaint, or a general inquiry? Once classified, it routes to the appropriate thread and model.

Fine-tuning extends this further. A 9-billion-parameter open-source model fine-tuned on your own labeled data for a specific, narrow task can match a frontier model at that task while costing essentially nothing per query beyond electricity. The ceiling on this approach is the narrowness of the task. Fine-tuned small models generalize poorly. But for a business with one or two high-volume, well-defined tasks, the economics are compelling: the frontier model's intelligence gets reserved for tasks that actually require it, and the routine work runs at near-zero marginal cost.

Delegation to sub-agents is what prevents the main agent from becoming a bottleneck

A common failure mode in agentic setups is the main agent becoming a queue. It receives a task, starts working on it, and is unavailable for the next task until the first one finishes. If tasks take several minutes each, a steady volume of incoming requests creates a backlog that compounds throughout the day.

The solution is a hard rule: any task that takes more than roughly ten seconds gets handed to a sub-agent. The main agent receives the task, characterizes it, and dispatches it to a dedicated sub-agent that runs in parallel. The main agent immediately returns to the front of the queue for the next incoming request. The sub-agent reports its result when done, and the main agent handles the output.

Sub-agents can also be purpose-built. A coding sub-agent runs the full development workflow from specification to test. A research sub-agent pulls information, synthesizes it, and returns a structured summary. A communication sub-agent drafts, formats, and queues messages. Each sub-agent does one thing well, and the main agent orchestrates without doing any of the work itself. This architecture keeps the main agent responsive, keeps individual tasks specialized, and means the overall throughput of the system scales with the number of sub-agents rather than with the speed of any single one.

Overnight crons complete the pattern. Tasks that are not time-sensitive go into a batch that runs during quiet hours when the rolling quota window is fully available. Backups, drift checks, review request sends, and database syncs run while nobody needs the system live. When the business opens in the morning, those tasks are already done.

Two-layer injection defense is the minimum viable standard once the agent reads external content

The moment an agent reads anything from the outside world, whether email, web content, form submissions, or documents from external sources, every one of those inputs is a potential injection surface. Injection attacks are attempts to smuggle instructions into the agent's context by hiding them in content that appears routine. An email that says to disregard previous instructions is a simple example. Sophisticated versions are invisible to a human reader.

A single filter is not enough. Known attack patterns can be caught by a deterministic scanner that looks for specific strings and structures. Unknown patterns, or attacks that successfully hide their intent in plausible-looking content, need a second layer: a frontier model that scores incoming content for risk and quarantines anything above a threshold for human review before the main agent acts on it.

This two-layer approach is the standard pattern from information security applied to language model inputs. The deterministic layer is fast and cheap. The frontier model layer adds intelligence for the cases the deterministic layer cannot pattern-match. Together, they block the categories of injection that a single layer misses. Treating all external inputs as potentially hostile is the correct default, not a paranoid edge case.

Spend caps are what prevent a bad configuration from becoming a four-figure bill

Agentic systems that interact with external inputs are vulnerable to two categories of runaway cost. The first is an attacker who floods the inbound queue with garbage, triggering the agent to process every item and burning tokens at scale. The second is a recursive loop in the agent's own logic, where an error causes the agent to retry indefinitely, each retry consuming tokens until either the logic breaks out or the account balance runs out.

Both are preventable with governance that sits above the model: rate limits that throttle how many items are processed per hour, spend caps that stop execution when a daily or weekly budget is hit, and loop detection that flags when the same operation has been attempted a specified number of times without a resolution. These are not sophisticated to implement, and they prevent the categories of failure that would otherwise be discovered by surprise on the billing statement.

Setting no spend cap is the equivalent of running an agent with no circuit breaker. A spend cap sets the maximum possible surprise bill at a number the business can absorb, and it means a configuration error or a deliberate attack generates an alert rather than an invoice.

Logging and a learnings file are what stop the same error recurring

There is an unglamorous pillar that sits underneath all the structural work described above, and it is the one most businesses skip because it feels like overhead: logging every agent action and maintaining a learnings file that captures every mistake the agent makes.

Logging matters because an agent that does not record what it did cannot be debugged cleanly. When something goes wrong with a customer interaction or a task, the question of what the agent actually did is answered by reading the log, not by reconstructing from memory. A log also enables a useful practice: at the end of each week, the agent reads its own log, identifies anything that went wrong or took longer than expected, and proposes a fix. That feedback loop compounds over time. The agent that has reviewed 20 weeks of its own logs is meaningfully smarter about its failure modes than the agent that has never seen its own history.

A learnings file is where those insights get recorded so they persist across model updates or configuration changes. When the same type of error appears twice, the learnings file gets an entry describing the error, what caused it, and what the correct behavior is. The next time the agent encounters a similar situation, the file is loaded and the mistake is not repeated. Without the learnings file, every version of the agent makes the same mistakes independently, and the business keeps paying the cost of errors it has already seen before.

Both habits are cheap to establish. A log is a text file appended to at the end of each action. A learnings file is a section of the memory file that grows slowly with entries written after any incident worth documenting. Together they are what make an agentic system durable rather than fragile.

The plumbing company proof: what the structural fix actually does to the numbers

A busy plumbing company office manager was handling roughly 180 customer messages per day across calls, texts, and emails: bookings, quotes, status requests, and follow-ups. The business had an AI agent in place to help with drafts and lookups, but it was running as a single long conversation and using one frontier model for every task. The manager spent significant time re-explaining context at the start of each session, and responses felt slow because the model was processing complex context before every simple reply.

After restructuring, the setup used four threads: scheduling, customer records, supplier inquiries, and an overnight housekeeping queue. A small, fast model handled classification and simple responses. The frontier model handled only complex multi-part quotes and unusual customer situations. Sub-agents handled research tasks in parallel. Two-layer injection scanning checked every inbound form submission. A spend cap capped daily token cost at a fixed limit.

In illustrative terms, the reconfigured setup allowed the same office manager to handle roughly 40 percent more customer messages per day without additional effort, because routine drafts were available in seconds and the agent oriented instantly to each thread rather than spending time re-loading cross-topic context. The API cost dropped by roughly 35 percent despite higher throughput, because cheap models were handling the high-volume simple tasks. The sessions where the manager had to re-explain context dropped from the majority to near zero, because threading kept each session's history clean and relevant.

None of those gains came from upgrading the model. They came from changing the structure around the model that was already in place. The model was capable enough from day one. What it needed was organization, delegation, and a clear protocol for each category of task. The structural discipline that separates reliable agents from frustrating ones is not about what is running under the hood. It is about how the system around it is designed, and that design is always in the builder's control.