Applied AI engineering · LLM systems · coding agents
The model is the easy part. I work on everything around it: the tools it can reach, the state it reads, the context it gets, and how you would know any of it worked. I build in public and publish what actually runs.
Areas I actually spend time in. Building, breaking, and reading about. Some of it is work, some of it is study. None of it is a rating.
Most of my time goes here. What an agent can see, what it is allowed to touch, and how much of the loop stays under a person's control.
Deciding whether a change actually helped. I am more interested in a test that fails honestly than a number that looks good.
The plumbing around a model call: how context gets assembled, where state lives, what happens on retry, and the places where a system quietly goes stale.
Running models on my own hardware, to understand cost, latency, and what breaks when nothing is hosted for you.
Currently learning: how a model is shaped after pretraining, and how that shows up later as behaviour you have to design around.
Two projects. One is live and working, one is still being built. Nothing here is filler, and nothing unfinished is dressed up as finished.
A fictional university Biology course planner where a person and an AI agent act on the same live application state through WebMCP tools. The agent reads the plan and can replace the selected courses, but it cannot touch the scheduling preferences the human owns. Change the page yourself and the agent's next read sees that newer state, not a stale snapshot.
get_course_planread current state
set_course_planbounded course replacement
A local-first tool for AI coding agents, aimed at project context, evidence, scope, freshness, invariants, and human-controlled authorization. Foundation components are implemented in the repository. It is still under development, has no published release, and there is nothing to demo yet.
foundationimplemented
releasenone yet
I started closer to AI automation, wiring tools together and seeing what held up. That pulled me toward the harder questions underneath: how an agent gets its context, who owns the state it reads, how much authority it should have, and how you would even know it worked.
Now most of my time goes into coding agents, evaluation, and running models on my own machine. I learn in public, and I would rather show one thing that runs than five that only demo.
Not a methodology. Just the rules I keep coming back to when a system starts getting away from me.
Evidence first.
A claim about a project traces to something you can open, run, or read.
Human approval.
A person stays in control of anything consequential. The agent proposes, the human decides.
Real experiments.
Build the thing and watch it fail. A demo that only works once is not a result.
Verify, then say done.
Rendered, clicked, and checked before it gets called finished. Not inferred from the source.
Understandable systems.
If I cannot explain how it works at three in the morning, it is too clever to keep.
I record what I am building — the parts that work and the parts that do not.
YOUTUBE / @heytenzyCoding agents and evaluation, mostly. The WebMCP Course Planner is the one project that is live; Evidline is the one I am still building.
Running models locally on my own hardware, and post-training: how a model gets shaped after pretraining, and how that shows up in the behaviour you end up designing around.
On GitHub. Both projects above link straight to their repositories, all under github.com/TenzyZ
Yes, especially on agent harnesses, evaluation, and anything where a person needs to stay in control of the loop. Email is the fastest way to reach me.
It lets a web page expose tools that an AI agent can call, so the agent and the person work against the same live application state instead of the agent guessing from a screenshot. The course planner is my working example of that.
