Software Engineer, Agent Infrastructure

About Sapiom

Sapiom is the end-to-end platform that removes barriers to ship and scale agentic products.

We unify what an agent needs to act in the world — compute and sandboxes, memory, identity, spend controls, storage and queues, monitoring — provisioned together as one thing, not handed over as a framework to assemble yourself.

We have assembled a world-class team with deep infrastructure and payments DNA to build the operating system for machines. Our founder ran payments engineering at Shopify for five years and built an autonomous consumer agent company before that. We raised a $35M Series A led by Dragonfly in August, bringing us to $50M total. Accel led our seed; Menlo Ventures and Anthropic are also behind us.

The models are the brain. We're the spine.

About the role

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.

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.

What you'd work on

Sapiom Builder. Today, authoring an agent means bringing your own coding agent: Studio launches the user's Claude Code or Codex in a terminal and injects our prompts, MCP, and authoring skills. We don't own the model, the loop, or how good any of it is at building Sapiom agents. We're building a Sapiom-managed model specialized in authoring and managing agents, with that expertise as a versioned, evaluable artifact instead of prompts assembled at launch time. It's the top item on the roadmap and our biggest source of friction.

Making the builder ask the right questions. Studio can generate an agent from a spec and then fall over when that agent has to reach a customer's internal services, databases, and credentials. The authoring flow should surface those access requirements systematically, up front, instead of leaving them to be discovered at deploy time. One of the clearer wins available.

Version awareness and rollback. Editing a deployed agent should visibly flip it to draft, and a user should be able to tell what's running in production. Neither is true today: there's no deployed-version fingerprint, and no rollback.

The onboarding golden path. Template browse, clone, build, run. Some of that works and some of it is a hardcoded gallery. Every new user comes through here on the way to a working agent.

Canvas and step inspection. Logs, latency, step-level input and output, error states that tell you something. This is where a user reconstructs what an agent did.

The desktop app. Electron, signed releases, one-click install, and cross-platform support we don't have yet. Desktop is the experience we point customers at first.

Agent packaging and ingestion. How an agent gets from a local directory into something the platform can run, versioned and reproducible.

You may be a fit if

• 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.

Applying

A recruiter screen, then a technical screen. If those go well, a three-part loop: an architecture deep dive, a hands-on AI project, and a conversation with our founder.

Everyone on our engineering team carries the title Member of Technical Staff internally.