Building a software factory with Python and AI agents
Most coding-agent demos end when the model produces a patch. In production, that is where the work starts.
A coding agent on a laptop is a good tool and a poor system: it runs as you, on your machine, dies when the lid closes, leaves no record, and its only gate is you pressing merge. We built a software factory in Python that gives a team what the laptop does not. A structured Jira ticket goes through specification, research, estimation, coding in an ephemeral E2B sandbox, review, a dev deploy with a live check, and a merge request that a person still has to merge.
This talk is about why that architecture works: a durable Temporal workflow that retries one stage and survives a worker restart; typed Pydantic handoffs the workflow branches on; one model gateway with a scoped key per agent; prompts, rubrics and context in a reviewed registry; one run id across traces, transcript, branch and ticket; and gates where a person acts with a scored spec and a verified deploy in front of them.
The evidence is one week in July: the same change run in three repositories. The first run failed and the records said why. We changed the inputs, not the model, and the next two ran in 1 h 45 min and 28 min.
You'll leave with an architecture you can adapt and a rule for deciding what to automate, retry, measure, escalate, or hand to a person. Intermediate Python; no Temporal experience needed.
This intermediate talk is for Python engineers who build, or are considering building, LLM agents that change real repositories. No prior Temporal or LLM-observability experience is needed.
It is a case study of a working internal system, told from the architecture outward:
- Six things a laptop coding agent does not give a team, and the runtime that does: receiver with a policy decision, durable workflow, worker, sandbox, gateway, tracing, registries, secrets.
- Eight reasons it works, one slide each: the sandbox and in-box verification; one gateway and a key per agent; durable orchestration and a definition of "stuck"; typed handoffs; the registry; one run id; the human gates; deterministic checks over model judgment, including a hallucination detector we demoted after measuring it.
- The loop run once: a failed run, what the trace and the ticket showed, the fix, and the two clean runs that followed. Shown from recorded transcripts and traces, not a live demo.
- What the factory does not check yet, and where to start if you build one.
Tools appear as examples: Python 3.13, Temporal, Pydantic, LiteLLM, Langfuse, E2B, pytest. The takeaway is the architecture and the habit of treating each run as evidence for the next change.
I build Data & AI functions that turn fragmented foundations and isolated AI experiments into trusted platforms, reusable products and measurable business outcomes.
Across DanAds, Readly, Schibsted and HBO Max, I have led work spanning enterprise AI, data platforms, analytics, machine learning and governance. Outcomes include supporting a product initiative that achieved a 14% conversion uplift, reducing per-user LLM licensing costs by 90%, cutting projected annual feature-store costs from $450K to $230K, and supporting the HBO Max launch across 23 European markets.