Artifacts & Agents: A Guide to Agentic Programming

The industry is a little drunk on coding agents. Every week there is a new word for the same pile of prompts: loops, graphs, harnesses, stacks. Maybe we just go back to calling it “programming”.

There is also a lot of talk about memory, context layers, and agent development lifecycles. Everyone claims they’ve figured it out, but the reality is that we’re still all learning exactly how to use this magical genie in a bottle.

Underneath the noise, a lot of us are starting to get real work done. Here are four principles that made a difference for us.

1. Pick the right artifacts

People spend a lot of energy squeezing more performance out of the agent. We got further by caring about what it reads and what it writes.

An agent takes something in (a markdown doc, a Jira ticket, a human prompt) and emits something out (another markdown doc, a code diff, an email). Call those things artifacts. You can run a surprising amount of a company as agents handing artifacts to other agents. That is what we have been doing.

A meeting transcript goes into a product agent and comes out as engineering tasks. Those go into a coding agent and come out as a PR. The PR goes into a review agent, then a deploy agent, then an analysis agent asks whether any of it worked.

Choosing the artifact turned out to matter as much as building the agent. What should a coding agent eat: a markdown spec, a GitHub issue, a Cursor plan, or a vague thought salad from a Slack conversation? What should a product agent eat: a custom prompt, an OKR, a Jira issue, or a pile of MCP tool results?

Where the artifact lives matters too. That is what makes it auditable, searchable, and changeable. Dumping everything into markdown in a Git repo is convenient for agents. It is also how you accidentally recreate the problem every “memory layer” startup is now selling a cure for. Pick an artifact people already know how to open, argue about, and revert. The good ones are easy for an agent to chew on and easy for a human to read.

This is why, at Thor, we keep putting work back into the tools teams already like, and making those tools less hostile to agents.

2. Use deep but narrow agents

A swarm of tiny agents with tiny toolboxes is easier to predict. It is also a maintenance nightmare, and it wastes what the models are good at. A single mega-agent with a thousand tools is the opposite problem: slow, sloppy, and hard to debug.

Give the agent enough tools to check its work, try a second approach, and get unstuck. Keep the job small.

If it can be a script, make it a script. Save the model for the part that needs “thinking”. Checking out a git branch should not be a prompt. It should be a command you run before the agent even starts. Same for reading files, opening tickets, filling forms. AI is a bad substitute for laziness. Use it where intelligence is the scarce ingredient.

Our best agents still have a lot of tools but they’re given an extremely tiny assignment. The entire prompt for our Product Code Review agent is this:

Your input is a code diff, PR description, list of related tasks and their high level product goals. Use the tools at your disposal to audit this work for accuracy and reply back if you believe this work deviates too far away from what product vision we have defined.

That beats an agent that also has to know how to clone the repo, load the tracker, find related tickets, and wander Google Drive looking for the goals doc. Hand it the artifacts. Tell it to be suspicious. Let it use whatever tools it needs to prove itself wrong.

If the inputs and outputs are solid, you do not need a “company brain” or a memory platform sitting in the middle. A product like Thor can help get you there quickly but you can also script this yourself with some elbow grease.

3. Break jobs into tasks

The tempting move is to replace a role with one agent. Give it every tool that person had, write a prompt that describes their whole day, drive it via cron jobs. We tried a version of this. It sucks. The job is too big, and the decision points hide in the middle. You still want a human somewhere. At the start, before anything exists? At the end, after the mess is already made? Both options are bad.

What works is splitting the job into tasks. Not a “Marketing Agent”. A “Content Writer” agent, an “Ad Expert” agent, a “Landing Page Optimizer” agent. Each one has one job and a set of artifacts. You know immediately if it’s doing a good or a bad job.

If you’re just starting to build such agents, have a human read every output and tweak the knobs of the agent until you get quality results. When the output is boringly good, you take the human gate off that step.

By the way, we have not replaced our marketer. You still want a person steering. You just stop asking that person to write ads, build landing pages, and audit blog posts for accuracy. One person can cover ground that used to take a small team.

4. Plans and specs slow down innovation

“You don’t know what a program should do until you play with it. So in the agentic age, you should resist the temptation to be overly specific upfront. Be as vague as you can to manifest something, then interact with the something.” — DHH

This was true before agents. It is still true. You cannot spec your way to software people love. You get there by using the thing, hating parts of it, and changing it. Specs get useful after something has clicked, as a record of where you came from. They are a lousy map of where you are going.

Ideas feel magical in your head. Why has nobody done this? Often because it is a bad idea the moment it leaves your imagination. Wasabi ice cream sounds brilliant. No amount of taste-bud chemistry and lab experiments will tell you if it is. You have to put the literal wasabi into the literal ice cream and then lick it.

Churning out ice cream can still take days. Software now takes minutes. So just do it already.

If you want to wire these principles into the agent setup you already have, that is what we are building at Thor. Get started free.