I Spent Five Months Taming GoClaw. Then I Gave Up and Built My Own System.

Or why ten users can teach you more than a thousand GitHub stars.

Let me start with a strong opinion: at any company with more than three or four people, local agent harnesses should be banned. Maybe confiscate the developer’s keyboard while you’re at it.

A local harness is a great way to indulge a programmer’s ego, lose everything they’ve learned when they leave, waste hours setting up MCP servers, services, and development environments all over again — and eventually let an agent do something spectacularly stupid on a machine where it has local administrator privileges.

The problem is that there are hardly any mature, multi-tenant harnesses available off the shelf. And the few options that exist often require assembling a complicated system from separate parts.

For five months, I tried to build a proper environment for corporate AI-assisted development out of existing open-source components.

I didn't need another chat interface with a button labeled Run agent. I needed a system where an agent could take a task, break it down, delegate subtasks, wait for people, produce artifacts, pass quality gates, fix problems, and come back to the person who requested the work with evidence — not just a cheerful “Done!”

I started with GoClaw and spent months extending it. Then extending the extensions. Eventually, it started to feel less like using open source and more like signing up for a long-term job maintaining someone else's product.

Then the first ten users showed up.

Suddenly, the system was much less capable than I needed and much less reliable than I expected. It became painfully slow and kept crashing. Long-running tasks were difficult to manage properly. The human-in-the-loop (HITL) functionality wasn't sufficient for the workflows I needed, so approvals, review cycles, and returns for rework had to be bolted on through workarounds.

Ten users aren't exactly a world-scale load test. But if a system starts acting like a temperamental child at that scale, it's probably time to reconsider a few things.

So I did. And eventually, I started building Temporality.

Not because all open source is bad, and not because I suddenly developed an urge to rewrite everything from scratch. The reason was more mundane: I wanted system-level guarantees without having to keep attaching another stick to the pile of sticks I'd already attached.

1. I Didn't Need an Agent. I Needed a Working Organization.

Most agent frameworks are pretty good at answering a particular question: how do you give a model tools, run its execution loop, connect MCP servers, spawn subagents, and get a result?

That's useful. But in corporate development, a task doesn't necessarily begin with a tool call or end with a model response.

Suppose I ask an agent to prepare a new feature for an internal product.

It needs to:

1. Talk to Alex and Peter, gather information, and resolve contradictions.
2. Produce a requirements artifact with sources.
3. Get it reviewed by the relevant department head.
4. Wait for my approval.
5. Only then start development.
6. Follow the quality checks defined in the artifacts associated with the skills it uses.
7. Run automated tests and attach the results.
8. Send the implementation to Nick for approval.
9. Once Nick approves, return to me with the final artifact, the process history, and evidence that every required gate was passed.

These aren't nine bullet points to put in a prompt. They're a workflow with state, participants, permissions, dependencies, waiting periods, and consequences when someone says no.

Alex doesn't respond. Now what?

Peter gives contradictory information. Who resolves it?

The department head sends the requirements back for revision. Do we restart everything or resume from the appropriate step?

I haven't approved the requirements yet. Can the agent start coding anyway because the model decided that things looked “clear enough”?

No. It can't.

And if an agent restarts, a service gets deployed, a subagent fails, or someone responds several hours later, the workflow shouldn't turn into an archaeological expedition through logs and chat history.

That's where the problem stops being “make an intelligent agent” and becomes “build an environment in which an agent is actually allowed to work.”

2. HITL Is Not an “Approve” Button

Human-in-the-loop functionality is often implemented like this: the agent asks a question, the user responds, and execution continues.

That looks great in a demo. Real workflows have a few more complications.

People might not respond. They might reject a proposal. They might change the requirements. They might approve one artifact but reject another. A decision needs to refer to the specific question and the version of the information on which that question was based. And some actions simply must not happen until permission has been granted.

If an agent asks, “May I delete the database?” and the user clicks No, that's not just another message in a conversation. It's a decision that must affect execution.

When the agent resumes an hour later, it must not repeat the same operation under a different name. And if the plan has changed since the approval was granted, the system must not silently assume that the old approval still applies.

HITL is therefore part of the execution model. It needs explicit states, a stable identity for each request, a record of the decision, and defined behavior for rejection, timeouts, and resumption.

This isn't limited to dangerous operations. Requirements reviews, acceptance decisions, hypothesis confirmation, and choosing between alternatives are all normal parts of work that you can't simply hand over to a language model.

The funny part is that these ordinary requirements are often the ones developers end up implementing in the most extraordinary ways.

3. Context Isn't Infinite. Neither Is Attention.

During development, another idea gradually took shape: agents need not only a token budget, but also an attention budget.

This isn't just a fancy name for a context-window limit. The problem is broader.

An agent can burn hundreds of thousands of tokens rereading history that has almost nothing to do with the current task. Subagents can investigate the same area repeatedly. The context can accumulate outdated knowledge, long reports, intermediate reasoning, and instructions that no longer apply to the current state of the workflow.

Technically, everything might fit. Practically, the important stuff drowns in noise.

As knowledge accumulates, every new run makes it harder to identify what's actually relevant.

The longer the task, the more obvious the problem becomes. One agent investigates the code, another writes tests, and a third reviews the result. If every agent receives the entire history, we don't get collective intelligence. We get collective rereading of the same journal.

An attention budget should determine what the agent needs to know now and what should remain available on demand.

In practice, that means:

• The current task and its constraints take priority over general history.
• Delegation context should contain the goal, relevant data, and acceptance criteria — not the parent's entire conversation.
• Verified experience is more useful than a random note from a previous run.
• Detailed evidence should remain accessible without being dumped into every new context.
• Model usage, tool calls, retries, and subagent work must count against the budget of the overall task.

That last point matters. If a parent agent delegates work to five subagents, each subagent shouldn't magically receive an unlimited budget unrelated to the parent's budget.

The idea behind the Agent-SRE Toolkit was to account for execution resources across the delegation chain. A task consumes resources as work progresses; delegating doesn't magically multiply the budget.

This is simultaneously a cost, control, and reliability issue. If the agent has already spent most of its budget investigating the problem, perhaps it should narrow its hypotheses. If a mandatory verification step is still ahead, it shouldn't spend everything producing the first implementation.

A budget isn't merely a limit imposed on an agent. It's a way to make the agent plan its work knowing that verification, fixes, and accountability still lie ahead.

4. Why I Stopped Fixing Someone Else's System

Back to GoClaw.

I'm not going to argue that GoClaw is unsuitable for everyone. It has its own use cases and users. And an open-source project isn't obligated to be a ready-made corporate platform.

But I had specific requirements. After bringing in roughly ten users, I was seeing performance degradation and recurring crashes. At the same time, the HITL and multi-stage workflow mechanisms I needed couldn't be added simply by flipping a couple of configuration options.

Each individual problem was fixable. The trouble was that the cost of every change increasingly depended not just on what needed to be implemented, but on how to fit it into the existing execution model.

That's an unpleasant moment in software development. You look at the next task and realize that, technically, it's perfectly solvable. The real question is how many new exceptions, workarounds, and special cases you'll need to introduce without breaking the things you've already fixed.

And then there's the sunk-cost trap. Five months invested. A pile of code already written. Surely one more push will make everything fall into place.

But time already spent is not an architectural argument.

I decided to stop and move what I considered fundamental requirements into a separate system: durable execution, observability, control, human decisions, and the evolution of agent experience.

That's how Temporality started.

Not as “the fork where I finally fixed everything,” but as an attempt to build a control plane where these capabilities are part of the architecture rather than a collection of add-ons around an agent loop.

5. Temporality: Execute, Observe, Control, Improve

The experience timeline: knowledge, its lifecycle, and its history over time.

Temporality has four interconnected layers.

Execution. Long-running tasks, delegation, plans, and pauses while waiting for human input. Temporality uses Temporal for durable workflow execution. Restarting a process or deploying a new version shouldn't, by itself, destroy the state of ongoing work.

Observation. An event history of execution: model calls, tool actions, state transitions, and human decisions. It's not enough to know that a task failed. You need to reconstruct what happened and why.

Control. Policies, permissions, approvals for consequential actions, access management, and execution restrictions. An agent shouldn't acquire new privileges simply because the model decided they'd be useful.

Improvement. The system should extract experience from completed tasks, validate it, track the results of reusing it, and stop using knowledge that has proved wrong or become outdated.

These aren't four independent checkboxes on a presentation slide. They depend on one another.

Without observability, it's hard to understand why an agent failed. Without control, letting agents change their own behavior is dangerous. Without durable execution, long-running workflows with human approval steps are unreliable. And without a mechanism for evolving experience, every new task starts almost from scratch — or with a collection of random notes nobody has verified.

6. Agent Memory Isn't a Folder of Wise Quotes

In discussions about agent systems, memory often seems to mean writing something to a file and adding that file to the prompt later.

For short tasks, that can be perfectly adequate. For long-running development involving multiple agents, it quickly becomes problematic.

Suppose an agent discovers a workaround for a bug. That doesn't mean the workaround is universally valid. It might work only with a particular library version, in a specific environment, or under a lucky combination of conditions.

Save it as an unconditional instruction, and the system hasn't become smarter. It has simply learned to reproduce an old coincidence.

In Temporality, I separate execution history from the knowledge extracted from it.

The event journal records what happened. Knowledge is a projection of experience that can be reused. Hints supplied to an agent are a compact representation of relevant experience, not a dump of the entire memory into its context.

That knowledge needs a lifecycle. It can be proposed, confirmed, challenged, corrected, superseded, or invalidated.

This isn't about making a diagram look impressive. If a rule turns out to be wrong, merely stopping its recommendation isn't enough. You need to know where it came from, where it was used, and which conclusions might depend on it.

Agent evolution: versions, evaluation gates, and changes in resource consumption.

The system must not confuse three different statements:

• “The agent did this.”
• “The result turned out to be useful.”
• “We've verified that this approach is worth reusing.”

Those are three different events. The work of accumulating experience happens in the gap between them.

7. A Skill Needs a Contract, Not Just a Good Name

Skills have a similar problem.

A skill isn't merely a text file explaining how an agent should behave. A reusable procedure needs input conditions, an expected result, and quality criteria.

If a skill modifies code, you need to know not just that it finished, but which checks the result must pass. If it gathers requirements, you need criteria for completeness and a way to verify that the sources haven't been lost. If it performs code review, you need to define what qualifies as a finding.

A skill as a versioned procedure with explicit runtime requirements and checks.

In this model, a skill becomes an executable contract between a task and its expected result.

That raises another question: what happens when an agent proposes an improvement to the skill itself?

You could apply the new text and hope for the best. Hope is cheap, but it doesn't scale particularly well.

Instead, a change should go through an evaluation loop: a set of test scenarios, an evaluation of the new version, and a clear verdict. A failed evaluation is not a success. If the evaluation mechanism itself has degraded, it must not give the change a green light simply because it failed to identify a problem.

Temporality's current quality loop includes evaluation suites, runs tied to specific agent-definition versions, human feedback signals, harvesting candidate test cases from real runs, and a gate that controls the application of changes. The LLM judge is calibrated against historical human decisions; if its agreement falls below the required threshold, it is considered degraded and its result cannot pass the gate.

This doesn't mean quality can now be fully automated. It means changes no longer get accepted solely because they look convincing.

8. Agent SRE: Watch the Trajectory, Not Just the Answer

When an agent runs for a long time, its final response tells you very little about what actually happened.

It might have wasted its budget on pointless retries, called the wrong tool, delegated incorrectly, ignored a rejection, or received bad output from a subagent — then somehow produced the right final text by sheer luck.

Conversely, an agent might have followed the process correctly almost to the end but failed because an external system was unavailable. You can't distinguish these cases by looking at the final status alone.

That's why the Agent-SRE approach interests me: not just the correctness of the final answer, but the health of the execution trajectory.

How many retries were needed? Where did delays occur? Is resource consumption increasing from one version to the next? Is the parent passing too much context to subagents? Which failures keep recurring? Which human decisions consistently correct agent output?

It's important not to confuse observability with a collection of attractive graphs. The goal isn't to create another dashboard with green circles. The goal is to collect evidence that lets us change the system and verify the consequences.

An execution trace: model calls, tool steps, and human decisions.

That's why I care about the event history, its connection to the original task, and the ability to reconstruct the sequence of actions. Otherwise, after the next incident, we'll be discussing not what happened but what the model probably meant.

In incident investigations, the word probably usually means we're short on evidence.

9. What About Security?

A corporate environment can't assume that an agent will always behave sensibly. Even without malicious intent, it can misunderstand a task, run an unnecessary command, or misuse a tool.

Recently, I had a particularly entertaining example. I gave an agent an encrypted archive. Instead of asking me for the password, it wrote an archive-cracking utility and started melting my laptop.

The agent's intentions may have been perfectly innocent. Its choice of method was less so.

Temporality uses a restricted Docker sandbox for command execution. Networking is disabled by default; network access requires explicit permission. Containers run with limited privileges, a read-only root filesystem, a constrained workspace, and resource and execution-time limits. Host environment secrets aren't passed into the container as ordinary environment variables.

There is an important caveat. The sandbox protects against agent mistakes and unauthorized actions within its threat model. It doesn't make a compromised Docker daemon or host kernel safe. Granting network access also expands the attack surface, and fine-grained domain filtering is a separate capability — not something a single checkbox magically provides.

I spell out these limitations because “our agents are secure” too often translates to “we added --network=none and now we're hoping for the best.”

Controls must be verifiable, and trust boundaries must be documented. Otherwise, security is just a feeling the development team has.

10. Can We Measure Performance?

Yes, but the measurements need to be interpreted correctly.

The repository contains a reproducible load-test scenario using a deterministic OpenAI-compatible mock provider. The heavy profile includes four model turns, two sandbox command executions, an HITL pause with a simulated human response, and a final response.

This is useful for testing how the platform behaves under concurrent load. It is not proof that every real agent will respond in 6 ms. The model is mocked, so actual provider latency, rate limits, and cost aren't included in those figures.

Why publish these tests at all? Because after the experience with ten users, I wanted more than “trust me, it'll be fine this time.” I wanted a way to measure the effect of changes. The tests and scripts for reproducing the scenarios are in the repository.

And yes, a load test can be wrong, too. The documentation even records an incident where the mock tool's contract didn't match the expected payload: the tests could pass even though the intended sandbox command was never actually executed.

That's exactly the sort of thing worth discovering before a green chart becomes the team's only source of confidence.

11. What Came Out of It?

Temporality is an open-source, self-hosted runtime and control plane for agent systems. The source code, documentation, and current interface are publicly available:

• Website: https://temporality.ext.io/
• GitHub: https://github.com/RuslanGabbasov/temporality

I'm not going to claim that I've solved every problem in agent development. I haven't. Some scenarios still need work, individual mechanisms have limitations, and having code and tests is no substitute for independent auditing and operating the system under different conditions.

But the project now starts from a different set of assumptions.

Instead of trying to squeeze a corporate workflow into the loop prompt → model → tool → response, I'm building a system where long-running execution, human decisions, event history, permission control, and verifiable accumulation of experience are part of the architecture.

For me, that's the main lesson from those five months: the complexity of an agent system isn't determined by how clever its answers are. It's determined by how predictably it behaves when the task is long, there are multiple participants, something goes wrong, and nobody wants to reconstruct the entire process manually from a chat transcript.

Open source remains an important part of the solution. But open code doesn't mean the system you need is already there. Sometimes you can combine existing components successfully. Sometimes their architectural assumptions don't match your requirements, and the cost of adaptation grows faster than the functionality.

And sometimes the right decision is to stop fixing someone else's bicycle, even after you've replaced almost every part of it.

Especially when that bicycle is supposed to carry people, get its route approved by a department head, and deliver its test results to Nick along with a proper report.