Agentic Claude Code Tooling
Custom agents, skills, and a self-hosted VM for autonomous AI workflows
2025 – present
I rigorously followed LLM research since 2022, even upgrading to a 5070ti GPU to run and fine-tune local models from Hugging Face. The field moved too fast for me to have played with every tool — creating and moving on from RAG, LangChain, vector databases, and a million other tools to supplement the shortcomings of prior LLM models. My focus had been to ensure I can maximize my own capabilities when using both lower-quality (local) models and frontier (proprietary) models like Claude or ChatGPT. Since 2025, I believe that AI has finally passed a threshold where a well-informed user is capable of automating a majority of computer-based tasks. With the introduction of AI harnesses, I have worked on my own scripts and tooling to benefit proprietary models running on my machines. I primarily use Claude Code and have written my own "Agent Skills" and custom scripts to interact with the agent harnesses and accelerate my work.
If you're interested in following AI research as well, I recommend following Anthropic's research page. I also recommend this paper: Symmetry in language statistics shapes the geometry of model representations, which uses concepts like months and years to show how an LLM can have cyclical structures to represent historic dates and the months of the year.
VM Sandboxing
In the early days of Claude Code, I created my first autonomous-agent by linking the harness STOP-hook to a prompt-injector, pointing the agent to a task list and a set of scripts to monitor its session limits and manually control the loop. In this setup, an agent could pause the loop and programmatically wake itself up if it was within 90% of the 5-hr session limits. With this scaffold, I was able to run Claude Code tasks overnight, monitoring my PyTorch training sessions and debugging machine learning pipelines.
With later upgrades to the Claude Code harness, specifically the Discord and Slack integrations, I began to use Discord as a primary method of communicating with my sandboxed agents, allowing them to share files over the app and run local dashboards that I can access from my host PC.
Custom Computer Use Tools
While computer use has been an LLM benchmark for several years now, it is still a fairly new consumer-facing tool with frontier labs taking a slow approach to releasing their official implementations. Currently (July 2026), Codex and Claude Cowork offer computer-use functionality through their harnesses.
Instead of waiting for the proprietary solutions, I wrote my own scripts in Python to send keyboard and mouse commands, take screenshots, and allow my agents to create their own "macros" for repeatable tasks. The main benefit of this approach is not only having intimate knowledge of your tool's capabilities (as opposed to the opaque implementations and safeguards that come with proprietary tools), but also the ability to selectively expose computer-use to your agents and even reserve it for subagents. In my testing, Claude Haiku (small model) is very capable of navigating a computer by sight and following direct commands from larger models like Opus, saving many tokens over long sessions that depend on visual debugging.
(In Progress) LLM Documentation Parser
Before 1M token context windows became common, 250K context windows were extremely restrictive for LLM-based projects and large code-bases. As a solution I'm currently iterating on, I direct my coding agents to write high-level documentation snippets within code comments, preceded by a special character. This way, a fresh agent can run the parser at the top level of the code repo and receive the high-level documentation, its associated files, and precise line numbers.
This approach towards documentation leverages the harness' built-in tools and the way LLMs have been trained. When your coding agent writes a file, it is capable of making changes by targeting specific lines or by string-search and replacement. With the provided line numbers, reading large files no longer guarantees context-bloat as an agent can parse the documentation and selectively read the most relevant lines to make its changes. For high-level "managerial" agents, the documentation also aggregates a simplified view of the code-base, highlighting core functionalities and dependencies across the codebase. Likewise, by updating line numbers and associated files automatically, the parser beats any project-map that an agent may make for you and forget to update. The documentation lives and depends on its code, and as long as your agent doesn't forget to update its docs, it is incredibly resilient.
Dedicated Manager & Worker Agents
I have a dedicated template for my agent-led projects that include my tools and agent definitions. The most important part of the template is actually its Manager & Worker agent files. By giving a manager agent general guidelines to minimize file reads, terminal commands, and other tasks that rapidly occupy its context window, and to delegate tasks to its worker, I found that my agents remained coherent over longer sessions and were more successful on their tasks.
For my personal projects, I prefer to have more control and oversight of my agents as they work. One pain point of delegating tasks to worker subagents is that they report to the main agent rather than to you, the user. To solve this problem, my worker agents write their timestamped summaries in a dedicated "agent-notes" folder for future verification and aid when debugging files whose original author has already been freed.
I recommend making your own Manager & Worker agent files if your projects follow similar directory structures or if you face recurring issues similar to the ones described above.
Forward-Deployed LLMs
One real-world benefit from using LLMs came during a Bioprocessing Lab at UC Davis. Time-series data needed to be recorded from a bioreactor's oxygen probe, but its automatically recorded data was collected every 30s rather than every 1s. To get around this, groups recorded the reactor's screen, which displayed live probe readings, and manually recorded the values later. With 20 videos, each over 3 minutes long, some groups understandably took up to a week before getting around to finishing their data annotations. My group finished by the end of the day.
During the downtime between trials as the systems returned to equilibrium, I had my groupmates send me all the videos and pulled up Claude Code on my laptop. Using FFmpeg and a Python Jupyter Notebook, I was able to split each video into 1s-separated frames and place them into folders. I then shared those folders with a Claude-generated HTML page capable of loading the frame folder, accepting data entry, and automatically saving the input to a spreadsheet while iterating to the next frame. By sharing the HTML page, even my non-technical groupmates were able to use the tool since it only required access via their web browser.