> Markdown version of [/jobs/ext/4621964-software-engineer-agent-infrastructure](https://www.wearedevelopers.com/jobs/ext/4621964-software-engineer-agent-infrastructure). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Software Engineer, Agent Infrastructure

- **Company:** Precision Inc.
- **Location:** San Francisco, CA, United States
- **Experience:** Expert
- **Contract:** Permanent contract
- **Skills:** Application Programming Interfaces (APIs), Artificial Intelligence, Software Applications, Cursor, Software Design Documents, Programming Tools, Node.Js, AI Coding Agents
- **Published:** November 7, 2026
- **Apply:** https://www.juju.com/job/28_25303_592577e8dc7e13e19669b040d19c1231

## About the Role

This is a senior role, roughly four to seven years of experience. Agent Experience has grown past the point where it can be a rotation. It needs someone who owns it full time.

## Description

Agents can think. Getting them to act in production is still hard: teams build a good demo in days, then spend months on the cost, reliability, and control problems that follow. The thing breaks when nobody is watching. The bill arrives before the explanation. Nobody can reconstruct what happened. Closing that gap is what Sapiom does.

Agent Experience is how a builder meets that platform. Agent Studio is where someone authors an agent, watches it run, sees what it did, and ships it. If that surface is bad, nobody gets far enough to use the rest of Sapiom. The work is full-stack: a desktop app, a canvas, a step inspector streaming live from production runs, and the services behind all of it.

One position we've taken deliberately: we are not a coding IDE. Pointing an agent at an existing codebase and asking it to integrate Sapiom produces bad results. What we do is clean-slate agent authoring, optionally seeded from a spec or design doc. Keeping that scope narrow is the point - it shrinks the surface, and it's why we aren't trying to be Cursor., * You've owned a product surface long enough to live with your decisions: shipped it, watched people use it in ways you didn't intend, and changed it.

 * You've built developer tooling that people kept using after the first week, and you have a theory about why.
 * You write both halves - you've designed an API and the thing consuming it, and you know which side you got wrong.
 * You've shipped software onto machines you don't control: desktop, CLI, SDK, anything you can't hotfix at 2am.
 * You've cut scope on something you wanted to build, and you can say what you cut and why that was the right call.
 * You've held a position on how something should work, and changed it when someone showed you better.
 * You use AI tools in your own engineering workflow.

Nice to have: Electron or desktop application packaging; canvas, graph, or node-editor interfaces; live-streaming UI backed by long-running processes; experience with coding agents, MCP, or agent authoring tooling; evaluation harnesses for model-backed products; a stint owning developer experience somewhere.
#J-18808-Ljbffr