We used to tag Linear. Now we tag ArtBot.

Ideas often start as a Slack message. They turn into a Linear ticket in a backlog. Then it was prioritized, and if it wasn’t urgent it waited and waited. When it got picked up, someone started fresh, read the hopefully well defined ticket and/or the hopefully linked conversation, and rebuilt context.

Today we just tag ArtBot (a coding agent built on the Claude Agent SDK) right in the thread. It reads the conversation, investigates thoroughly in code and cloud environments, opens a pull request, and records and posts an annotated video recording of UI changes with the test plan items checked off one by one. 

Why do we need one when we have Claude, Codex, and Cursor already all living in our Slack org? Because it runs in our container, with our libraries pre-installed, access to all of our tools, and with safe access patterns.

In the six and a half weeks since it went live, ArtBot has opened more than 1,500 pull requests — about 130 a week at steady state — and 740 of them have already merged, triggered by 27 engineers typing its name into Slack. Half of those PRs merged within two hours of being opened; 40% merged within the hour.

Killing the prioritization inertia didn’t just get PRs made faster. It enabled work to get done that otherwise never would have.

The first big decision: the ticket was never the point

Which project? What initiative? Who is it assigned to? When is it due? What priorities do we have to compare it to? Sometimes this work takes more time than the ticket. 

So why make a ticket?

First we optimized the ticket making. Guidance on who/what/where/when for the agent to figure these out. It’s the natural extension of what everyone already did by hand.

It made the ritual faster, but do we want to do it at all? 

Do we want to still have the growing backlog, the prioritization decision, the lost and regained context by multiple people. 

A huge class of requests don’t need it: just do it.

That reframing killed the ticket-writing assistant. We weren’t building a better way to file work. We were building a better way to do the work.

The obstacle is the way

Opening a PR is easy. Merging a PR is easy. Ensuring it’s a high quality PR is hard.

And then, like magic, it started reproducing the issue, and…. it broke halfway through.

😅

I’m frequently reminded that the hard part is often the unexpected part and just getting everything to run is hard sometimes too. Luckily, Artbot also posts detailed error messages, and because it’s our custom built bot, it has permissions to see the logs of its previous startup sequence running and failing. 

Without that access, it will hallucinate some reasonably sounding reasons why it failed and spin its wheels and yours for a couple hours.

With that, it can heal itself:

4 hours and 36 minutes from a report in #qa to a merge that included infrastructure changes and redeploys. And we haven’t bumped the disk again since!

What we’d tell another team

The interface you already have beats the interface you’d design. We didn’t build a portal, a CLI, or an IDE extension. We put the agent where the work was already being described (the Slack thread). Adoption wasn’t a rollout; people just started tagging a different name. If your users are already talking about the work somewhere, that somewhere is your front door. Don’t make them go somewhere new to ask.

Solve security structurally, not with a careful prompt. Prompt engineering isn’t a security boundary, it’s a suggestion. The thing that actually protects our infrastructure is that the agent’s IAM role literally cannot read it. A broker service authenticates. Assume the agent will, at some point, be talked into doing the worst thing its permissions allow — then make sure the worst thing is harmless. Draw your trust boundaries in infrastructure, and let the prompt be about doing the job well, not about staying in bounds.

Compound interest is the most powerful force in the universe. Artbot can run any skill in our repo because of its environment. So it runs /poke, /make-pr, /bazooka-fix (yes that’s the actual name, you’ll need to wait for Sergey Semenko to write another blog post), /improve-tests, /test-video and /monitor-pr which have all taken chunks of work from hours to minutes individually. Now days of work can be done end-to-end.

It’s demo time. A video is worth a million words. Give your agent the ability to clear success criteria and the ability to check its own work and the ability to show its work to the team. It will be able to work autonomously to completion, and you’ll be able to verify it worked. Until of course, you trust it enough that you don’t watch the video any more. 

We’re not quite there, but we’re working on it.

What’s next

The frontier now isn’t “can the agent do the task” — it’s “how much of the task can it own end to end.” 

Right now a human still reviews and merges. The interesting open questions are about trust calibration: which classes of change are safe to auto-merge behind green CI, how an agent should signal its own uncertainty, and how it should escalate — back into the same Slack thread — when a request is genuinely ambiguous rather than guessing.

The fixes everyone agreed on (but nobody had an afternoon for) stop accumulating.  The work just happens, in the thread, while the context is still warm.

The small tweaks required to make a delightful user experience are shipped continuously, oftentimes in the same day when they surface. What’s the outcome of that? Customers say this: “Everyone at Artemis should know, it is in the top three of my favorite tools. Really, it’s in the #1 spot right now. I look forward to using it every morning.”