blog.cygankiewicz.com

cezar-agent-orchestrator

Open Mercato Hackathon in Wrocław - #aveCezar!

How I extended Cezar at the Open Mercato hackathon with machine telemetry, dispatch limits and an adaptive admission governor. Human in the loop, agents in worktrees.

Published:10 min read

  • ai-agents
  • open-source
  • hackathon
  • developer-tools
Key visual of the #aveCezar hackathon: a statue of Caesar in a dark, technical style, the #aveCezar wordmark and the line Build Cezar with Cezar
Key visual of the #aveCezar hackathon team. The tagline: resource awareness, scale control, human in the loop.

TLDR: Cezar is ⚡️🚀

On Friday morning I only knew that Cezar existed. By Saturday night I had a dozen or so worktrees, a herd of agents, a string of pull requests headed upstream, and Cezar building… Cezar itself.

That is roughly what my weekend at the Open Mercato hackathon in Wrocław looked like.

I am not going to pretend this is an objective post. After two days of heavy use, I think Cezar is one of the most interesting tools I have discovered this year.

First - what exactly is Cezar?

Cezar is an open source orchestrator for coding agents.

Instead of opening five terminals and five Codex sessions and trying to remember which agent is doing what, you get a cockpit for running many tasks in parallel.

Every task can get its own Git worktree. Tasks can work in parallel. Extra tasks wait in the queue. You can use Claude Code, Codex, OpenCode or pi, build workflows in YAML, wire up checks and watch the agents work live. There is no separate database either - Cezar keeps its state in ordinary .ai/cezar/ files.

The most interesting part, though, begins when an agent can delegate work to further agents.

That mechanism is Dispatch.

In broad strokes:

Human
  ↓
Lead agent
  ├── child agent
  ├── child agent
  ├── child agent
  └── child agent

The lead receives a larger task, breaks it down and delegates smaller pieces to its children. The children work in parallel in their own worktrees, and the leader collects the results.

Sounds great.

Until you start wondering:

how many of those children can we actually run safely?

The problem showed up on its own

While using Cezar I quickly reached a point where delegation was at once its greatest strength and a potential problem.

If one agent can launch several more, and each of them does real work on the same machine, you need more than a simple “run the next task”.

You need control over scale. Patryk, one of Cezar’s co-creators (https://github.com/pat-lewczuk), pointed me toward the real problem on Saturday evening: measurement and autoscaling. I dropped the feature I had been building that day, because telemetry and adaptive control simply had more value.

The first step was therefore a simple mechanism:

Max running dispatched tasks

A human sets a hard limit on how many Dispatch-launched tasks may run. If the limit is 4, the fifth child does not start immediately. It waits in the queue.

Ordinary tasks are not blocked by this.

That matters, because a manual limit is simple, predictable and leaves the last word with the operator.

I did not want to remove it later.

Quite the opposite - it became the foundation for what came next.

Cezar's Resources panel with a manual limit on dispatched tasks
The Resources panel: Max parallel tasks is set to 2, while Max running dispatched tasks is empty at this point, which means no limit. That second limit covers dispatched tasks only - ordinary tasks keep running as usual. Source: a screenshot from Cezar taken while working on this post.

OK, but how much can this machine actually take?

When I started thinking further about limiting agents, an obvious question came up.

How is anyone supposed to know whether to set 2, 4, 8 or 16?

That is how the next piece came about - live Machine telemetry.

A card appeared in Resources showing, live:

CPU, memory, load average, the core count and a short CPU trend.

No Prometheus.

No Grafana.

No extra telemetry agent.

No database.

Just the current state of the machine.

And even that alone was very useful to me.

Cezar Machine card with live CPU, RAM and load average telemetry
The first version of the Machine card: CPU, memory, load average and core count, all refreshed live. In this variant the card showed host resources only - the note Host totals - no cgroup limit detected for this process. states plainly that no cgroup limit was detected for this process. Source: a screenshot from Cezar, Machine card v1.

Except that a far more interesting problem showed up a moment later.

The host says one thing, the container another

The first version of the telemetry showed host resources.

On an ordinary machine that is fine.

But Cezar is very well suited to running on VPSes, sandboxes and containers. And that is where things get tricky.

The host may have:

24 CPU
58.5 GB RAM

while the Cezar process may really have:

2 CPU
1 GB RAM

If the scheduler only looks at the host, everything looks great.

“Relax, we have 58 GB of RAM.”

Meanwhile the container is just about hitting its own 1 GB.

That was the moment a plain telemetry widget started turning into something far more interesting.

I added cgroup detection and effective capacity.

If the process runs with cgroup limits, the Machine card shows the resources that actually apply to that process. Host totals stay visible as context only.

So on a single screen we see:

effective:
2 CPU
952 MB / 1 GB

host:
24 CPU
58.5 GB RAM

And suddenly we have information we can genuinely make decisions on.

Cezar detecting cgroup-v2 limits and the container's effective capacity
The same card inside a container: cgroup limits detected - cgroup-v2, effective 2 CPU and 88 MB out of 1.0 GB of memory, while the host's 24 CPU and 58.5 GB RAM drop to the role of context. The process now sees its own limit, not the resources of the whole machine. Source: a screenshot from Cezar inside a 2 CPU / 1 GB RAM container.

Fine. So Cezar can see machine pressure…

…which means it does not have to merely display it.

It can react to it.

And this is where my favorite part of the project begins.

On top of the manual cap I added an adaptive admission governor.

The rule is very simple:

the human sets the maximum; the automation can only reduce that limit.

The manual limit does not disappear.

If I enter:

Max dispatched tasks = 8

then 8 is a hard ceiling.

The governor cannot say:

“you have plenty of free RAM, so I will let 14 through”.

No.

What it can do is see memory pressure and say:

“you set a maximum of 8, but right now it will be safer to admit 4”.

That, to me, is the right human-in-the-loop model.

human ceiling
      ↓
effective machine capacity
      ↓
adaptive governor
      ↓
dispatch admission

8 -> 4 -> 8

The best part is that this is no longer an architecture diagram.

It works.

For the test I ran Cezar in a container with:

2 CPU
1 GB RAM

The manual Dispatch limit:

8

On a calm machine:

Dispatch admission: normal - 8 of 8

Then we load the container’s memory.

The Machine card climbs to around:

952 MB / 1.0 GB

and the governor moves to:

Dispatch admission: elevated - 4 of 8

So it does not change the user’s configuration.

It does not stop children that are already running.

It simply admits fewer new tasks.

When the memory pressure disappears and the system stays calm for a moment:

4 -> 8

We are back to normal admission.

And that is when I thought:

OK, this widget is not a widget anymore.

It has become an entry point into the orchestrator’s control loop.

Adaptive admission governor in the normal state - 8 of 8
Normal. There is no pressure, so the governor admits the full 8 of 8. Container memory is 88 MB out of 1.0 GB.
Adaptive admission governor under memory pressure - 4 of 8
Elevated. Memory climbs to 952 MB out of 1.0 GB and admission drops to 4 of 8, even though the manual limit is still 8.
Adaptive admission governor after the pressure cleared - normal again, 8 of 8
Normal again. The pressure is gone and admission returns to 8 of 8; container memory is 86 MB out of 1.0 GB.

Build Cezar with Cezar

The most meta part of the whole story?

Most of this work was done using Cezar itself.

One development tree went through 27 tasks:

1 lead
8 implementation
15 review
3 research

Up to 5 agents worked in parallel, and at one point I had 14 worktrees.

One agent implemented a piece.

Another reviewed it.

Another did QA.

Reviews were able to find real problems, the implementation got fixed, tests were re-run, and only then did the change land in a PR.

In one case the review caught a really nice detail - the sparkline showed host CPU %, while the number next to it already represented the container’s effective CPU.

A small thing.

Except it is exactly such small things that make telemetry stop being trustworthy.

Fix, test, new screenshot, on we go.

That is probably the biggest thing I took away from this weekend.

It is no longer only about “AI will write my code”.

More like:

idea
↓
lead agent
↓
dispatch
↓
worktrees
↓
implementation
↓
review agents
↓
QA
↓
human
↓
PR

The factory works.

The human still stands by the red button. 😎

My first weekend as an open source contributor

For me personally, this hackathon was also my first serious step into working on someone else’s open source project.

Fork.

Branches.

Spec PR.

Implementation PR.

Review.

CLA.

Rebase.

Conflicts.

Upstream.

More fixes.

And somewhere in the middle of all that, the moment:

“holy crap, my code is actually sitting there as an open PR in a project I use”.

That feels very different from building yet another side project of your own.

Here the solution has to fit more than your own workflow.

It has to fit the existing architecture, the project’s philosophy and the people who will maintain it later.

Where does Open Mercato fit into all this?

The hackathon was organized around the Open Mercato ecosystem.

Open Mercato is an open-source foundation for building CRM, ERP and commerce systems in TypeScript. The project provides ready-made architectural decisions and foundations such as multi-tenancy, RBAC, events and domain modules, so that both developers and coding agents do not have to reinvent the basics of the system every time.

Cezar grew out of that ecosystem.

And after this weekend I understand much better why.

If you really want to build software with many agents in parallel, the problem very quickly stops being:

“which model is the best?”

It starts to sound like:

how do I manage all of it?

Queue.

Worktree.

Delegation.

Review.

Budgets.

Resources.

Admission control.

Human-in-the-loop.

And that is exactly where Cezar gets interesting.

What comes next?

As I write this, my changes are still open PRs waiting for upstream review.

And that is how it should be.

Open source is not git push --force to production. 😉

Regardless of how many of these things eventually land in main in exactly their current form, I already know one thing:

Cezar stays in my workflow.

⚡️🚀

EDIT - 21:25, 21 Sep 2026

PS. The secret sauce for operating the factory floor at capacity is the Open Mercato skills collection:
https://github.com/open-mercato/skills

I was very lucky to have the chance to watch Piotr Karwatka’s live coding session at the Open Mercato Hackathon in Wrocław on Saturday, 19 Sep 2026.

The recording is available here:
https://www.youtube.com/watch?v=VEy3JOwH_ew

It is in Polish only for now.

Piotr is a co-founder of Open Mercato and one of the co-creators of Cezar:
https://github.com/pkarw

Pull requests from the hackathon

Cezar repository: https://github.com/open-mercato/cezar

Open Mercato: https://github.com/open-mercato/open-mercato