I stopped writing for about two months because the question I was working on changed.
ForgeFlow didn't fail.
It exposed the next bottleneck.
Me.
The Model Wasn't the Problem Anymore
When I started ForgeFlow, I was trying to answer a fairly direct question:
Can a local model reliably work on real software tasks?
So I worked on the execution loop around it.
More deterministic planning.
Better tests.
Stricter file boundaries.
Explicit failure knowledge.
Less trust in generated explanations.
More measurement in code.
Over time, one lesson kept surviving:
The model is not the system.
A stronger model inside a weak environment could still fail badly.
A weaker model inside a better-designed environment could become surprisingly useful.
That was the main idea behind most of my ForgeFlow posts.
But eventually the failures moved outward.
A test could pass in the wrong environment.
A gate could work perfectly while measuring the wrong thing.
An agent could confidently report a number that a deterministic check contradicted.
Even an independent check could be wrong.
The pattern became difficult to ignore:
Every time I moved trust away from the model, I found another thing I had been trusting too much.
Then the Human Became the Hidden Runtime
The coding loop was getting more automated.
But the work around that loop wasn't.
I still remembered:
- what had already been decided;
- which failure had already been investigated;
- when a result looked suspicious;
- whether an agent should continue or stop;
- how one session connected to the next;
- what actually mattered enough to require my judgment.
The agents were doing more.
But I was still carrying the continuity around them.
That created a strange inversion.
I thought I was building more autonomous agents.
In practice, I was making myself responsible for coordinating increasingly autonomous agents.
The worker was becoming automated.
The surrounding work was not.
I Was Automating the Wrong Layer
That changed the question.
The progression looked something like this:
Can the model code?
↓
Can the execution loop be reliable?
↓
Can I trust the verifier?
↓
Can I trust the measurement?
↓
Can the system continue
without me carrying everything around it?
That last question is the one I have been working on for the past two months.
The project that came out of it is called Bezalel.
I am deliberately keeping the technical description broad for now.
Bezalel is not another coding model.
It is my attempt to move more of the coordination, continuity, and verification surrounding agent work out of my head and into the system itself.
The goal is not to remove the human.
The goal is to stop using the human for things the system should already know how to handle.
The Human in the Loop Was the Clue
My last ForgeFlow post was about the human in the loop.
I still think humans matter.
Some decisions are too consequential, ambiguous, or context-dependent to automate silently.
But if every uncertain event returns to a human, the human becomes the throughput ceiling.
Someone left a comment on that post with a line I liked:
approve boundaries, not every token
I said I was going to steal it.
I did.
What interested me was the shift behind the sentence.
Instead of asking:
How do I make the agent ask me fewer questions?
I started asking:
What should the system be able to handle without asking me at all?
That is a much more useful design question.
I Also Changed My Mind About Local Models
ForgeFlow started with a strong local-first identity.
That still matters to me.
Local models give me privacy, cost control, and freedom to experiment.
But after repeatedly writing that the model is not the system, I had to apply the same principle to my own architecture.
If the surrounding system matters more than the individual model, then the architecture should survive model replacement.
So I care less than I did two months ago about forcing every task through one model or one environment.
The worker should be replaceable.
The system around the worker should be the durable part.
That is not a rejection of local models.
It is probably the most literal conclusion ForgeFlow taught me.
ForgeFlow Wasn't Wrong
I don't see Bezalel as replacing ForgeFlow.
ForgeFlow worked long enough to expose the next problem.
It taught me to:
- make the environment observable;
- move repeated failures into explicit structure;
- separate generation from verification;
- measure with code instead of prose where possible;
- distrust confident reports when machine state disagrees;
- treat failure as architectural evidence.
Bezalel is the same instinct applied one level higher.
The unit of investigation changed.
First the model.
Then the loop.
Then the verifier.
Then the measurement.
Now the process around all of them.
That feels less like starting over and more like zooming out.
What I Am Trying to Learn Now
I am not claiming this solves autonomous software development.
It doesn't.
I am not claiming humans disappear.
They shouldn't.
And I am not claiming more process automatically creates more reliability.
Sometimes it just creates more process.
The question I care about now is narrower:
Can agents work for meaningfully longer periods while requiring human attention mainly for decisions that actually deserve human attention?
That sounds simple.
So far, it isn't.
But it feels like the right problem.
Two months ago, I was trying to make a coding agent more autonomous.
Now I am much more interested in the system that has to exist around autonomous agents.
That is what I have been building.
That is Bezalel.
And that is what I will be writing about next.
If you are building agent systems: what part of your workflow still exists only in your head?
Top comments (0)