Blogs
Featured blogs
Generated image: Villar David editorial
Blogs
Notes from what I'm working on.
Shorter posts on software, applied AI and product decisions, usually about something I've just run into or I'm still thinking through.
2026
Running Amp Orbs on my own workstation
I set up Amp's self-hosted Orbs on a Linux workstation with Docker. Here's what runs locally, how a thread starts and resumes, and what still goes through Amp.
Updating a procedure after a workaround
Coding agents are running longer and reading more context before they come back, so an out-of-date procedure matters more now. An agent can follow an old workaround a long way before anyone notices.
Checking an integration after the job says it finished
An agent can get most of a long task done and still miss something important, and I think integrations need the same split between the job finishing and the records actually being right.
What stays yours when the agent harness is managed
OpenAI's Agents API now hosts sessions, environments, context management, tool loading and subagents. You still have to define the work, the authority, the record and the recovery path around it.
Recheck the permission boundary when the model changes
OpenAI has put GPT-6 Astra at its Critical cybersecurity capability threshold. If you're moving to a model that much more capable, check the identity, tools and approvals around it before you treat it as a drop-in swap.
Coding agents are changing the economics of technical debt
Some migrations sit in the backlog because doing them by hand costs more than they seem worth. Parallel coding agents can change that maths, although only in a repo with clear conventions, tests you can trust and a definition of done a reviewer can actually check.
What I changed in agent memory
I now keep an agent's working context separate from durable records and searchable history. I changed it after watching old material get pulled into sessions where it was technically related but no use for the task the agent was actually doing.
A task-board export needs an experiment index
A task board can show that work moved and still lose the experiment behind it. I'd add an index that links each test to its question, evidence and result, so later work can tell what's safe to reuse.
Write the handoff before clearing the agent context
Before I end an agent session, I write down where the work actually stands and the command that should run next. Otherwise the next session has to piece it all back together and might redo changes that are already done.
A score needs a methodology readers can inspect
If your software gives an organisation a capability score, the person reading it needs to see what was measured and which version of the rules produced it. I'd keep that explanation right next to the scoring logic so it changes when the method does.
Write the evaluation set while the AI feature is still moving
Teams tend to leave evaluation until the prompt and interface feel finished. I'd rather collect the hard cases during development, because they show whether a change fixes the task or just tidies up the latest demo.
Govern the whole agent system
When I review an agent I trace what it can read, what it can change and how a person can stop or reverse it, which means looking at the harness and credentials as well as the model.
A conversational assessment still needs deterministic scoring
Let the conversation collect the evidence and let a versioned rule set do the scoring, so a reviewer can rerun the result and get the same answer.
What embedded AI delivery uncovers in the workflow
Sit with the team actually using an AI system and you'll find things the brief never mentioned: fields nobody trusts, exceptions handled outside the software and approvals nobody wrote down.
Build the searchable specification before the application gets expensive
When requirements are spread across PDFs, email and meeting notes, every piece of implementation starts with rediscovering the product. I'd pull the source material into a searchable specification and keep each decision linked to the evidence behind it.
Where agent supervision has to happen
Anthropic's numbers suggest experienced users let agents auto-approve more and also interrupt them more often. To me that says supervision should sit around a visible plan and the actions with real consequences, instead of a confirmation on every command.
The coding-agent interface is becoming a control plane
Once you're running several agents in their own worktrees with a review queue at the end, you're mostly supervising work that's already moving. The bits I care about are the boundaries you set, catching drift early and having enough evidence to understand each result before you merge it.
Production agents need institutional context
OpenAI's write-up on its in-house data agent is mostly about the context sitting around the model: schemas, code, permissions and saved corrections. What I want to know is who keeps that context right, and how a user fixes it when it's wrong.
Reconciling portals, permissions and integrations before release
In a multi-portal product, the last release checks tend to fail in the gaps between components: a role sees the wrong state, an integration updates late or two screens apply different rules. The examples here are a composite of problems that keep coming up in delivery.
2025
The agent’s activity log is part of the deliverable
When an agent changes code, data or config, I want its work record handed over with the answer, so whoever picks it up next can see what it tried, what passed and where it left things.
What I want from an always-on AI agent
I want an always-on agent to work like a worker with a job ticket: it takes a named job, leaves a record of what it did and puts any proposed change somewhere I can review it.
Operating local AI infrastructure after the migration
The migration's done, so now it's the boring stuff: services starting in the right order, data landing where I think it is, backups I can actually restore and failures I can see.
What has to survive when an AI assistant moves machines
Before I move an AI assistant to a new host, I'm listing the parts that have to survive and the test that shows each one did. Copying the prompt won't get me far, because most of the state lives in memory records, tools, scheduled jobs and the links back to source material.
Trying to remember everything made the agent worse
A total-recall experiment showed me that more retrieved history can crowd out the task the agent is actually meant to be doing. So I'm splitting memory into identity, durable decisions, project state and searchable archives, and choosing what loads by purpose.
One bulk query can beat thousands of careful loops
I've been working through data pipelines where perfectly reasonable queries add up to unreasonable runtimes. Moving the work into bulk operations helps a lot, but a bad bulk update can damage far more records before anyone notices, so the job needs a dry run, checkpoints and a way to reconcile the result.
What I am testing in long-term AI memory
I'm testing whether a graph can pull back a decision through what it's connected to: the person, the project and the source. What I want to find out is which records actually help the next session and which ones just make retrieval noisier.
Writing work orders for coding agents
Coding agents can now take an issue and hand back a pull request, so the issue is doing a lot more work than it used to. I want it to say what should change, where to look, what's in scope and how we'll know it works.
If software produces a score, the rules need a version
A score looks objective, but there's usually a changing set of weights, thresholds and assumptions behind it. I want the rule version stored with every result so someone can reproduce it, explain it and tell whether the answer changed or the evidence did.
Scoping tool access for an AI agent
OpenAI's Responses API lets one agent use search, files and computer use. Each of those gives the agent a different kind of authority, so I'd sort out its identity and approval rules before connecting any of them.
What DeepSeek-R1 changes in a model evaluation
DeepSeek-R1 is another open reasoning model you can test against your own work. I'd put it through the same evaluation set as everything else and look at task success, latency and what it takes to run before reading much into its benchmarks.
Long-running data jobs should be designed to stop
Big imports rarely fail at a convenient point. They need deliberate stopping points, a record of what's finished and a restart path that doesn't duplicate work that's already been accepted.
2024
Dates, dashboards and the work that has not processed
A dashboard can look current while timezone assumptions or a hidden row limit say otherwise. I'm putting unprocessed records, date rules and result limits on the screen, because people running operations need to see incomplete work before a customer complaint tells them about it.
Designing AI products around actions and state
Gemini 2.0 is being pitched around native tool use and agent-style tasks. If you're building in that direction, the product has to show what the model is doing, which action is waiting and what the user can still stop.
Accounting integrations need explicit sync state
An accounting integration gets hard to support once the app can't say whether a record is waiting, synced, rejected or changed afterwards. I'm making sync state visible so retries and reconciliation have something to go on, and staff don't have to compare two systems by hand.
What computer use exposes in business software
Anthropic's computer-use beta can click, type and move around software without a purpose-built API. So every vague label, hidden bit of state and irreversible button on your screens becomes something the agent has to deal with.
What I am testing with o1-preview
OpenAI's o1-preview spends more time reasoning before it answers. I want to test it on tasks where I can check the result without trusting the model, because the extra reasoning only helps if the answer holds up.
AI governance has entered the product backlog
The EU AI Act is now in force, with obligations arriving in stages. If you build product, I'd start by writing down where AI is actually used and who's responsible for each use.
Paid modules change more than the checkout screen
Adding paid access to a learning platform touches enrolment, permissions, completion records, certificates and support. I'd work through those before polishing checkout, because a clean payment page doesn't help much if the learner ends up with the wrong access.
Why I’m testing a graph for long-term AI memory
If an AI collaborator is going to work with me over months, it has to find its way back to who decided what, on which project, and based on what. I'm testing a graph-backed memory layer because those links get lost in a pile of transcripts, and I want to be able to check what it's stored.
Using voice and images in an existing workflow
GPT-4o puts text, images, audio and live video into one interaction. I'm more interested in the ordinary workflow side of that: what gets quicker to show, what still needs confirming, and what you need to keep.
When I would test an open-weight model
Llama 3 is worth putting into a real product evaluation. I'd run it against a hosted model on the same cases, then add up the hardware and the work of keeping it running.
The workflow that starts when a payment clears
When a payment clears, I want the right account updated, one message sent instead of three, and enough left behind that support can work out what happened if a later step fails.
How I decide whether an AI idea deserves a build
A convincing demo is easy to mistake for a product. I want to know who'd notice a wrong result, what they could check it against and whether the time saved is still there once you count the review work.
Start with the work people are already doing
If you build an AI workflow from the documented procedure, you'll usually miss how the job actually gets done. I'd watch the handoffs and workarounds first, especially the spots where people leave the official system to finish the task.
What applied AI means in my work
For me, applied AI starts with a piece of work that already exists. Before I pick a model or build a screen, I want to know the decision, what information is there, what delay costs and what happens when the answer's wrong.
Why I’m writing this down
I keep notes while I work, mostly because I'll have to explain a decision again months later. This journal is where I'll put the implementation details, failures and changes of mind I think are worth coming back to.