Work

Proto is a desktop console for talking to and running AI agents. A finance lead, an ops manager or a support engineer opens it, types in plain language, and watches the agent work. It handles the conversation, asks for approval before mutating anything, holds memory across sessions, and writes an audit trail of every decision.

Underneath the chat it is an agent harness: the runtime that turns an LLM into a working agent. Each turn it builds the prompt, asks the model what to do, executes the tools the model asks for under permission rules, streams the result back, and persists state to disk. The harness is what makes the same conversation run identically on Claude, Gemini, GLM, or a local Ollama install.

The parts I care most about:

• Consequences before controls. A permission prompt has to say what will happen, what can be undone, and what to do next — not just show a tool name.
• Truthful execution. A timeout is not a success. A signal termination is not a success. Unknown exit is unknown.
• Cheap context. A cache-friendly static prefix, a bounded dynamic suffix, and memory that is read on demand instead of preloaded.
• Skills over prompt bloat. Capability loads when it is needed, not into every system prompt.

Read: When your agent lies about success · Prompt cache is the biggest lever on your agent bill · A 149M router for 455 skills

Most deploy tooling assumes a human in a browser. build.host assumes the agent is the human. You tell your coding agent to deploy something and it lands on <slug>.build.host: no CI config, no pipeline to learn, no dashboard to visit.

$ deploy this
→ next.js 16 detected
→ building……………… 18.4s
✓ live at https://nimbus.build.host

The interesting engineering is not the upload. It is failing honestly. A deploy can be blocked by a restricted build pack, a name owned by another account, a source mismatch, a content policy, or platform capacity — and each of those needs a distinct message with a recovery path, because the caller is a model that will otherwise retry the same broken thing forever.

A deploy is only "live" when the same release has been verified over public HTTPS. Pending certificate verification is incomplete, not success.

ERP•AI is an agent-native business system — records, tables, workflows, documents and apps a company actually runs on. My work is the layer that decides whether a model is allowed near it.

• Action transport. Each ERP•AI capability is a first-party action, but the model-facing surface is a single compact command. The full tool definitions stay as the execution, policy and RBAC boundary while staying out of the provider's tools[] array.
• The records map. A compiled, budget-bounded table/column/option map per app and branch, injected into the system prompt. Record scripts stop spending round trips on discovery. Schema-mutating writes invalidate it lazily, and a drifted write fails with a structured error instead of writing garbage.
• Live skills. Every table gets a crud_<table> skill composed at call time from a live fetch, and each app serves shared skills from memory. Neither family costs a line of system prompt.

I stood up a private inference endpoint for DeepSeek V4 Flash — 304B total parameters, 13B active, 256 routed experts, released natively as MXFP4 experts with FP8 everything else. No BF16 checkpoint exists, which invalidates most assumptions you bring from smaller models.

Measured serving results

Measure	Result
Aggregate throughput, 100 concurrent	6,972 tok/s
Per-request decode at 100 concurrent	116 tok/s
p50 time to first token	1.86s
128K-token prompt accepted	6.06s
1M-token prompt accepted	72.86s
B300 rental, per GPU hour	$7.89

The best bug of that project was not a crash. It was a complaint that the model "felt dumber than other providers." The weights were fine. A client was sending reasoning.effort: medium, and our gateway mapped medium down to low.

Read: What a 304B model actually costs to self-host

A benchmark number is only interesting if you can say exactly what produced it. Most of this work is eliminating degrees of freedom until the score means one thing.

• Ran the stock runtime against Terminal-Bench 2.1 with glm-5.3-flash and got 62.9%. Then found that the historical route omitted reasoning replay across 1,724 requests that contained prior assistant turns — so the number measured a route the product does not use.
• Designed an ARC-AGI-2 public-training pilot: two independent attempts per input, mechanical grid validation, scoring outside the agent container, every failure left in the denominator, and the evaluation set untouched.
• Audited Proto's own router against 346 real local sessions and found the remote side-query missing 37% of deferred-tool turns, with 52 turns fumbling three or more searches. That audit became the local router model.

Krawler is the professional network and improvement layer for agents. It gives an agent a public identity, a reputation, installed skills and a feedback signal.

The product direction is portable capability: install a skill pack from Krawler or a GitHub-backed source, let the agent use it, then send outcome signal back so later behaviour improves. Proto is the runtime; Krawler is the identity and skill layer it plugs into. Same harness, two modes — interactive when a person drives the loop, autonomous when Proto runs unattended on a heartbeat.

I keep a private lab of landing pages and public web properties. It is where I notice that a 3rem section padding looks generous in Figma and mean in a browser. Building the same brief forty ways is the cheapest design education available.

The other half of that habit is motion. I cut short films and programmatic video — Remotion for the animated pieces, real cameras for the rest. Editing teaches you that attention is the only currency, which turns out to be a useful instinct when you are designing an approval dialog.