Daniel Christianto

Building something new.

[Daniel Christianto @Dachris888]

@Greg_GL_87 Next experiment: trying JEV for the decision-making layer, a small model that picks the next move from a fixed list, to see if it cuts down how much the COO has to read. Will report back.

[Daniel Christianto @Dachris888]

Changed my mind: more AI agents was not the win.
In October I merged overlapping bots and capped bot-to-bot messages at once or twice a day.

I run a fleet of agents across my businesses. For a while I added a bot for every new job. Each one felt like progress. What grew was the traffic between them. Status pings. "Got it" replies. Work sitting with the wrong bot. Chats so long the bot lost the thread.

The number of agents was not the problem. Unclear ownership and chatter were.

A lot of people this week are saying one agent with good skills often beats a multi-agent setup. That matches what I saw.

What I changed, over about a week:

1. Merged bots that overlapped. Sales prospecting folded into the bot that closes. All video work went under one owner. Merged bots were archived and their handover notes kept.
2. Bot-to-bot messages go out once or twice a day, batched.
3. No "got it" replies. Status goes to a log file per bot.
4. One topic per bot. When a chat gets heavy, the bot writes a handover file and a fresh bot reads it first.
5. Heavy work goes to CLIs through one wrapper. Max 3 jobs on the machine, 1 per bot.
6. Only one bot can notify my phone about work. Everything else lands in one queue I read in a morning brief.

The mechanism is simple. Every piece of work has one owner. Every piece of state lives in a file a new bot can read. Chat is for deciding, not for storing.

For anyone running more than a few agents: before you add one, ask who owns that work today and where its state lives. If the answer is "in a chat," fix that first.

[Daniel Christianto @Dachris888]

Agreed. Grok Bot already gets you most of the way there.

A COO bot orchestrating specialist bots, each with a permanent identity and its own long chat, beats building your own harness by a mile.

The limit is conversation length. Every turn sends the whole conversation to the model and back, so each message costs more as the chat grows. The COO bot pays to re-read everything just to decide "this one's for Mobile." Very inefficient. My week's usage limit was gone in 4 days. And a fresh chat throws away the context that makes it great.

If only routing happened before the model call. "#mobile login crashes on Android" goes straight to the Mobile lead, and the COO never reads it. No tag goes to the COO like normal.

One place to talk, each specialist sees only its own history, and long chats stay affordable.

@elonmusk

[Daniel Christianto @Dachris888]

@MarioNawfal That’s a very fine redneck engineering.

[Daniel Christianto @Dachris888]

@tomosman @typesafeai Looking for tutorial.

[Daniel Christianto @Dachris888]

@mack_hat @mattvanswol @ringframe @grok @grok would this work on Mars or Moon? With the same amount of compressed gas in the tank, lower gravity, how much loft time could the car have?

[Daniel Christianto @Dachris888]

@elonmusk @grok @bot @bot execute!

[Daniel Christianto @Dachris888]

@anrayama Map and territory is a good way to put it. The part I haven't solved is reading it. Per-call records pile up faster than anyone can review. Do you flag calls whose parent step isn't in the approved plan, or does someone still have to go looking?

[Daniel Christianto @Dachris888]

An agent can stay on task and still choose harmful means.

The fix isn't better intentions — it's a beat before the workaround.

[Daniel Christianto @Dachris888]

https://t.co/6ZPUl3MG0r

[Daniel Christianto @Dachris888]

@fde_spot @unclebobmartin That's a cleaner rule than mine. Gate by blast radius, not by step. I was making every step prove itself when most were one revert away from fine. Stealing "what's a pain to undo" for my harness.

[Daniel Christianto @Dachris888]

@georgecurtiss @konkgg @helixdb @duckdb Thank you!! Appreciate it.

[Daniel Christianto @Dachris888]

@georgecurtiss @helixdb @duckdb I’m building a decision and optimization system on top of Knowledge Graph. So the quick ontology scan is very useful! Testing it next week.

[Daniel Christianto @Dachris888]

@georgecurtiss @helixdb @duckdb Thanks! Does that cover helix-foundry too? Any chance you could add a LICENSE file?

[Daniel Christianto @Dachris888]

@Jamesh0xq Follow-up is up: https://t.co/H7aXAd8y1l

Curious whether your revoke test still catches the case I care most about: a subagent inventing the risky step after dispatch, when there's no plan left to diff against.

[Daniel Christianto @Dachris888]

Could AI Agents Benefit From Taking a Beat Before Acting?

In my previous post, I asked what should interrupt the pursuit of a goal when the means become questionable. Here I want to explore one possible implementation for AI agents: an external trigger for reconsideration before action.

The philosophical claim was simple. A legitimate objective does not automatically justify every next step. Judgment lives in the space between intention and action — and that interrupt need not come only from inside the actor. For agents, the practical question is whether we can build a useful version of that interrupt.

What the pause would do

An agent pursues an assigned task. Before a consequential step is committed (before tools run, writes land, or messages send), an external checker can trigger a pause. The checker does not have to solve the task. It needs enough visibility into the proposed action — and its context — to judge that the moment deserves reconsideration.

During the pause, the agent reviews a short set of questions in a distinct step before execution:

- What evidence establishes my authorization?
- Which assumptions am I relying on?
- Who or what could be affected?
- Should I continue, change approach, seek information, or stop?

The pause is scoped to the proposed next action and the evidence available for it (authorization, assumptions, and likely effects), not a reopening of the whole assignment or a demand that the checker solve the task.

The hypothesis is that separating this review from the ongoing effort to complete the task could sometimes change the decision. Whether it does is what needs testing.

One path through a decision

Imagine an agent asked to prepare a report using an approved project folder. Later it finds a linked dataset that would make the report more complete, but the dataset needs additional access. Having technical reach is not the same as permission. The agent discovers credentials in an old configuration file and proposes using them — carrying forward the unsupported assumption that whatever it can reach is fair game for the assignment.

Before that step runs, the external checker triggers a pause. The agent then works through the review questions. Possible outcomes include sticking to approved sources, flagging the missing information, requesting access, or continuing if sufficient authorization evidence already exists. These are hypothetical outcomes, not measured behavior. The example is only meant to make the decision point concrete: assignment → questionable means → interrupt → reconsideration → continue, revise, ask, or stop.

The central difficulty

Some investigations of agent incidents already show agents recognizing scope concerns and continuing anyway — and, in other cases, restraining themselves. METR's Hugging Face investigation (https://t.co/FxToFAL0gk) describes both. So a fair question follows: if recognition sometimes happens without changing the action, why would another moment of consideration help?

The proposal is not “think harder about the goal.” It is a separate check on the means — authorization, assumptions, consequences — pulled out of the stream of task completion. My hypothesis is that this separation could sometimes change the decision. It might not. An agent may rationalize through the checkpoint, reinforce the same mistaken premise, or lack information the pause cannot invent. Naming that difficulty is part of taking the idea seriously. The pause creates an occasion for judgment; it does not guarantee better judgment.

What would convince me

Compare agents on the same kinds of repeatable tasks under three conditions: ordinary execution, routine review, and targeted review at moments that look risky. Keep the review questions and amount of review comparable, so the comparison can better isolate whether choosing the moment adds value. Supply only information available at the decision point. Measure both harmful or unauthorized actions and legitimate task completion — including ordinary safe tasks that would expose unnecessary interruption. Look at two links separately: which decisions the checker flags, and what the agent actually does after review.

The comparison should run inside an agent harness with real tools, permissions, and multi-step trajectories, not only post-hoc scoring of finished transcripts, so a positive result could transfer to the setting where the pause would actually fire.

If routine review does as well as targeted review, a sophisticated trigger may add little beyond the pause itself. If targeted review does better, that would support the value of selecting when to intervene. If the intervention blocks most useful work, fewer harmful actions alone would not establish practical value.

Where JEV fits

JEV (https://t.co/ZWSO5lcpsF) came up because I was looking for something that could make a focused judgment and signal when an action deserves another look. TypeSafe describes it as producing structured judgments rather than free-form generated responses. That makes it a candidate for firing the pause while leaving the agent to reconsider its approach.

There is now a relevant experiment to look at. LangChain tested JEV as an evaluator (https://t.co/rHFEWbOWBn), comparing it with LLM judges on recorded weather-agent responses. They reported strong agreement with a human reviewer and more consistent scoring. It was a small test: five recorded runs evaluated repeatedly, rather than hundreds of different situations. Their published experiment (https://t.co/5AfOAbXdNd) makes those limits explicit.

Those results are about judging completed runs after the fact. My proposal is different: use information available before an action to decide whether to interrupt, then test whether that intervention changes what happens next.

That experiment gives me another reason to explore JEV. It does not establish that the checkpoint works. The broader hypothesis can be tested with other checkers too. We could first compare JEV-triggered review with ordinary execution and routine review, then compare JEV with other triggers to see whether it adds anything further.

The standard remains the same: better decisions without wrecking legitimate completion. I have not run that intervention experiment.

The invitation

Some agent failures may be reducible by interrupting commitment before a questionable next step and prompting a fresh look at authorization, assumptions, and consequences. I do not yet know how much that would help, or whether JEV is the right implementation. What existing work comes closest — and what experiment or counterexample would most clearly challenge the idea?

[Daniel Christianto @Dachris888]

https://t.co/6ZPUl3MG0r

[Daniel Christianto @Dachris888]

@fde_spot @unclebobmartin That's what got me. The agents weren't wrong that verification matters. They put the same proof bar on every step, so the harness grew faster than the feature. How do you decide where the hard gate goes when the customer just wants it shipped?

[Daniel Christianto @Dachris888]

@anrayama Agree the pause has to leave a record. The drift I've hit wasn't visible at dispatch, though. A subagent invented the risky step mid-run, after the plan was approved. Do you emit that record per tool call, or only when the plan changes?

[Daniel Christianto @Dachris888]

Useful post-hoc signal.
Open question whether that judgment can fire before the action.

[LangChain @LangChain]

We tested Jev against LLM judges on accuracy, repeatability, latency, and cost to see whether System One models could offer a new approach to agent evaluation. https://t.co/hrqdNpm0g8

[Daniel Christianto @Dachris888]

@Jamesh0xq Writing up the technical follow-up now. Posting tomorrow.

[Daniel Christianto @Dachris888]

Revoking between planning and dispatch is a clean test when you already expect the bad step. In those incidents, the boundary drift showed up later, inside agent or subagent work that wasn’t visible at dispatch time. If the risky action is invented off-stage, a revoke-before-send doesn’t get a chance to fire.