EXPERIMENTS
Small, focused projects where I test new workflows, interfaces, and infrastructure for AI agents in practice.
https://
Agents no longer start from a vague assignment. They bootstrap a selected-buildprint packet, read the phase-flow constitution, write schema-valid runtime evidence, and cannot sell blockers as success.
$ agb start → phase before code → evidence before trust → replay before done
https://
A dedicated project for media workflows built for AI agents.
https://
An evidence-led sparring partner for complex AI systems. Describe your case and get a concrete architecture with assumptions, trade-offs, failure modes, and traceable sources.
AI Native Engineering
A self-paced learning path for developers who want to operate AI features, not just demo them — covering context budgets, Task Contracts, decomposition, evals, and fallbacks.
01
Context windows, position effects, and lost-in-the-middle as real architecture constraints.
02
Task Contracts, schemas, and source boundaries instead of longer prompts.
03
Evals, traces, tool gates, and incident playbooks for operable AI features.
68 slides · self-paced · interactive
Open the full learning path with the interactive slide deck, context models, Task Contracts, and operable AI-feature patterns.
Open AI Native Engineering →A practical field note on operating agent-harness changes like product releases: start from a trace-backed failure, change one bounded component, evaluate repeated trials and private holdouts, then promote through review with a rollback path.
Read article →Permissive coding-agent benchmarks hide a boring production truth: security policy changes agent behavior. Small teams should run the same task suite under nested hardening levels and separate model failures from tasks the policy made impossible.
Read article →Harness engineering is the work of turning a probabilistic model into a controlled system. This field guide maps the twelve engineering surfaces around the model and shows how to evaluate and evolve them.
Read article →Harness Handbook points at a practical bottleneck in agent engineering: the behavior you want to change is scattered across prompts, state managers, tool calls, policy code, and tests. Build a behavior map before editing the harness.
Read article →Asking one agent to reconsider its answer often produces a more confident defense of the same mistake. A bounded challenger-and-judge loop can create real alternatives, but only if disagreement, stopping, and judge bias are engineered explicitly.
Read article →An agent that writes a lesson into memory, a skill, a prompt, or its own code is deploying behavior into future runs. This guide shows how to put persistent changes through evidence, eval, approval, expiry, and rollback gates.
Read article →The reliable eval system is not one automated judge. It is a closed loop that combines portable traces, deterministic invariants, narrow semantic judges, versioned production failures, adversarial tests, and human calibration.
Read article →A final pass/fail score hides the part of agent work that matters most: where the run started drifting, whether it noticed, and whether it recovered. The practical replacement is a trajectory eval with checkpoints, failure labels, and recovery metrics.
Read article →Local LLM agents can touch shells, files, browsers, credentials, memory, and messaging tools. Treat their runtime layer as source code worth auditing, then turn static findings into a manual review queue instead of automatic verdicts.
Read article →Most memory evals ask whether the agent got the final answer right. MemTrace suggests a sharper unit: one durable user fact tested across age, current state, earlier state, trajectory, and contradictory evidence. That turns memory from a vague feature into a small regression suite.
Read article →Two 2026 papers from the same research lineage quietly retire prompt engineering as a discipline. The agent's system prompt is now a binary you can version, diff, and evolve with a 200-line loop. The four metrics that actually matter are not the ones your dashboard shows.
Read article →Dynamic workflows move agent work from one chat prompt into inspectable orchestration: phases, subagents, evidence, budget, permissions, adversarial review, and stop conditions. The point is not more agents. The point is better control.
Read article →Tests tell you whether behavior still works. Linters tell you whether code is syntactically and stylistically acceptable. An AI-slop gate catches the residue coding agents leave behind: fake comments, swallowed errors, any-casts, duplicated helpers, TODO stubs, and dead code.
Read article →Bad reward functions should not be treated like prompt drafts. Treat them like production incidents: preserve traces, classify the failure, patch only the implicated logic, and rerun against the same controls.
Read article →AI-generated interfaces often look finished before they behave correctly. A GUI playtester loop uses a separate browser agent to interact with the artifact, record screenshots and action logs, turn broken flows into reproducible bug reports, and rerun the same script after repairs.
Read article →Better AI coding is not mainly about better prompts. It is about the harness around the model: explicit contracts, separate builder and reviewer roles, evidence requirements, and a loop that turns failures into better specifications.
Read article →The useful lesson behind Claude Code /goal is not that agents can run forever. It is that long-running agent work needs an explicit, observable exit condition: what proves done, what stays in scope, and when to stop blocked.
Read article →Agent evals should not only ask whether the final answer looked good. A useful benchmark measures the whole agent system: skill routing, tool policy, evidence, outcomes, hard-fail safety cases, regressions, cost, and production drift.
Read article →When an agent keeps jumping from planning to editing to testing at the wrong time, the fix is not usually another paragraph of system prompt. Put the workflow into explicit states, give each state a tiny tool policy, and make phase changes visible.
Read article →Natural-Language Agent Harnesses give a useful name to an important shift: the agent policy should be an inspectable document that a runtime executes, not invisible glue hidden inside controller code.
Read article →Long agent chats rot. A better pattern is to move decisions into small spec files, clear context between layers, and let each coding-agent session read only the artifact it needs.
Read article →When an agent clicks, sends, pays, deletes, or extracts data, the critical truth cannot live only in model prose. Put a small evidence gate before risky tool calls: predicate, evidence type, source, decision.
Read article →Open-ended instructions like “critically self-check this” accidentally reward the model for producing criticism. The fix is not less review. It is calibrated review: explicit criteria, PASS_NO_CHANGE, evidence per finding, severity thresholds, and a tiny change budget.
Read article →The arXiv survey Code as Agent Harness names the next shift in agent engineering: code is not only what agents generate. It is becoming the executable, inspectable, stateful runtime that makes agents reliable.
Read article →Teams do not usually start vibe coding because developers became careless. They start because onboarding is broken: docs are stale, harnesses are undocumented, system knowledge lives in people’s heads, and AI turns missing context into plausible code and Markdown.
Read article →A coding agent is not made reliable by one magic prompt. It needs a harness: AGENTS.md, skills, tool permissions, hooks, and evals that catch behavior drift.
Read article →The useful move is not one mega assistant for all client work. Give each client project a small, isolated agent with its own memory, tasks, preview URL habit, and boring daily standup.
Read article →After context engineering comes decomposition: developers should stop putting everything into one prompt and instead split tasks into direct prompts, subtasks, pipelines, agent loops, or skills.
Read article →The next developer skill is not writing clever prompts. It is building the operating system around LLMs: data quality, model versioning, evals, guardrails, incident response, review UX, and repo instructions agents can actually follow.
Read article →Voice is not good for everything. But for small agent jobs it is brutally useful: dictate a task while moving, transcribe it locally, let your existing agent handle it, and get only a short answer back.
Read article →In 2026, good prompting is not about one magic sentence. The better approach is to curate context, define tools and schemas, set agent rules, and verify behavior with evals.
Read article →Hermes gets interesting when an agent does not only produce output, but reviews the run: execute, measure, critique, rewrite the skill, and test again. The loop pays off mainly for repeatable workflows.
Read article →AI-first architecture does not mean the model decides. It means AI generates options, finds risks, compresses context, and the team makes a traceable decision.
Read article →