Staff Product Manager

OpenBox AI and Temporal have launched an integration that embeds governance directly into the runtime layer for enterprise AI agents. The system combines Temporal's durable execution platform with OpenBox's authorisation and attestation capabilities, automatically injecting governance checks into workflows before actions occur. Gartner predicts that by 2027, 40% of enterprises will scale back or abandon autonomous agents due to governance failures emerging after production incidents. The integration addresses this by ensuring every agent action is authorised, recorded, and recoverable through policies that can allow, constrain, require approval, block, or halt operations. Human approvals survive failures and restarts, whilst cryptographic attestations and immutable audit logs provide continuous evidence trails. The integration is now available for developers building on Temporal's platform, which is used by companies including Stripe, Netflix, and Datadog.

Why Monk, Inc. moved 100+ workflows to Temporal, one reversible PR at a time. June 18, 2026 Engineering Most teams migrate a live system one of two ways. They freeze feature work and move everything at once, betting the company on a big-bang cutover. Or they move the easy jobs, lose momentum, and let the half-migrated state set like concrete, so every engineer has to remember which jobs live where, forever. Monk, Inc. did neither. Monk, Inc. moved 100+ live workflows from Inngest to Temporal one reversible PR at a time. Both systems ran the whole way. No migration freeze. No rewrite. No downtime. Why Monk, Inc. moved off Inngest. Monk is an AI platform for accounts receivable. Its agents send invoices, run Intelligent Collections to chase outstanding ones, apply bank transactions to invoices, and sync everything into accounting systems and ERPs. Most of the product is autonomous and async. By the time Monk, Inc. started looking at Temporal, that async surface was north of a hundred jobs. Inngest was great for going fast on day one. At a hundred-plus jobs, it started hurting Monk, Inc. at scale. Finding the one run that misbehaved was slow. The "did we already do this?" idempotency checks were scattered across the codebase. A burst of high-volume webhook traffic could pressure the workflows running billing and customer-facing flows, because nothing isolated them. The decision to move was easy. The hard part was the how. You do not migrate a hundred running workflows in a weekend, and you should not try. Monk's agents move money, so the workflows have to hold. These workflows run for days. They call systems that fail in creative ways, like banks, ERPs, and email. And they cannot lose state halfway through. A retry that double-applies a payment lands on a customer's books. Temporal gives Monk, Inc. durable execution. A workflow's state survives crashes, restarts, and deploys. When a step fails, it resumes from where it stopped instead of starting over. The guarantees Monk, Inc. used to hand-roll in every workflow, like retries, timeouts, idempotency, and recovery, are now properties of the platform. Monk, Inc. don't have to get them right a hundred separate times. How Monk, Inc. ran the migration: one reversible PR at a time. Monk, Inc. never let a single workflow sit half-moved. Each one followed the same four steps, and each step was independently reversible and shipped small: * Characterize. Before touching anything, write tests that lock in what the Inngest job actually does: inputs, outputs, side effects, retry behavior, the branch logic nobody remembers. This is the safety net for every step after it. * Scaffold. Add the Temporal workflow and its activities alongside the Inngest job, with no traffic pointed at them. The new code ships dark. * Cut over. Flip the dispatch behind a feature flag scoped to a tenant. Route one canary tenant first, watch it, then roll forward. Roll back in seconds by flipping the flag. * Remove. Once the cutover is stable for a sprint, delete the Inngest receiver. High line count, lowest risk, because the code has not been receiving traffic. The reason this is safe: both paths wrap the same logic. The Temporal activity is a thin shell over the same domain service the Inngest job already called. The business logic keeps one home the whole way through, and the flag only chooses which runtime wraps it. The characterization tests hold that service still while the wrapper changes underneath it. Once the shape was muscle memory, the per-workflow cycle was a day or two. Every workflow Monk, Inc. moved has the same four commit titles, in the same order. Two speed bumps in the migration. Two of the Inngest-to-Temporal mappings caught Monk, Inc. out before Monk, Inc. learned to watch for them. Retries count differently. Inngest's retries: N means N attempts after the first failure. Temporal's maximumAttempts: N is the total, first attempt included. Port retries: 2 straight across to maximumAttempts: 2 and you have silently dropped an attempt. The correct mapping is maximumAttempts: N + 1. A step and an activity are not the same primitive. Inngest re-invokes your function over HTTP once per step and memoizes each step's result by its name. Temporal replays the whole workflow function from event history and hands back the recorded result of each activity. The consequence shows up the moment you port a function body: anything that sat between step.run calls in Inngest, a Date.now, a random pick, a quick read off the database, was harmless there because each step ran in a fresh invocation. The same line in a Temporal workflow body runs on every replay and breaks determinism. It has to move into an activity. Catch this, or you have copied the body across without migrating it. The thing you will miss most: flow control. In Inngest, capping concurrency per tenant is two lines of config. Inngest keeps a separate virtual queue per tenant and never runs more than your limit at a time. Throttle, debounce, rate limiting, priority, event batching, all the same way: declarative config, no code. Temporal is not built the same way. A worker can cap how many activities or workflow tasks a single process runs at once, but there is no native "run at most N workflows of this type" or "at most N per tenant." It has been an open, heavily upvoted request on the Temporal repo for years. So you build it. Two levers got Monk, Inc. back what Monk, Inc. gave up. Coarse: separate namespaces. Its highest-volume integrations can produce more events in an hour than most jobs produce in a day. They get their own namespace, worker pool, and ECS service. A flood there cannot starve the workers running billing and customer-facing flows. One Docker image, two entry points, picked per service. Fine: a coordinator workflow. Inside a pool, when you need a real per-tenant limit, one workflow lists the work and fans out children behind a sliding window, parking until a slot frees. The bug everyone writes first is forgetting to free the slot on the failure path, not just on success. For very large fan-outs, continue-as-new periodically instead of looping forever in one run. How Monk, Inc. deployed it. Workers run on ECS Fargate. Two services share one Docker image with two entry points. They autoscale on CPU, mostly on Fargate Spot with one always-on task as a floor. Spot is cheap and safe here, because Temporal reschedules any activity whose worker gets reclaimed mid-run. What changed. The hard wins: * Per-workflow visibility. Every run has searchable attributes, full history, and a status. Finding the one that misbehaved is quick. * Idempotency by construction. Deterministic workflow IDs replaced an entire class of "did we already do this" checks. * Workload isolation by namespace. High-volume webhook ingestion is structurally separated from core workflows. A burst on one cannot pressure the other. The soft wins: * New engineers ship their first workflow on day two. Every workflow has the same shape, so the only real learning curve is the determinism constraint. * The pattern stuck. The four-PR loop is muscle memory across the team now, and the same shape applies to the next migration off any framework. Boring on purpose. Monk, Inc. write a lot about building boring agents, systems that stay predictable because the stakes are high. Durable execution is the same idea one layer down. Monk, Inc. would rather spend its time on the AR problems no one has solved than reinvent retry logic. Pick infrastructure with hard guarantees, give every workflow the same shape, and put the creativity into the product. The full technical write-up. Frank wrote the complete, code-level walkthrough on the Temporal blog, including a single workflow mapped piece by piece, the full Inngest-to-Temporal mapping table, and the coordinator-workflow code. Monk, Inc. is hiring. If moving a live system one reversible PR at a time sounds like your kind of problem, Monk, Inc. is building a team of engineers who want to do hard things at the application layer. Browse its customer stories, or see open roles. Automate Accounts Receivable with Monk Monk brings together collections, cash application, and forecasting. 40%+ DSO reduction. $1B+ in receivables managed. 26 hours a month back to your team.

AI agents are entering their rebuild era as enterprises confront the reliability problem. As enterprise AI agents move into production, organizations are confronting a growing reliability problem. Many teams are discovering that LLM performance alone does not determine whether agents succeed in production. Long-running AI workflows must survive crashes, preserve state, recover from failures, manage inference costs, and coordinate across APIs, tools, and enterprise systems. After a first wave focused on rapid deployment, organizations now need to revisit those first-generation implementations, and redesign early agent architectures around workflow orchestration, observability, governance, and recovery, said Preeti Somal, Senior VP Engineering at Temporal Technologies, during the latest AI Impact Series event in New York. "We do have a lot of customers that come to us where they're building version 2.0 of the same agent," Somal said. "They had to move really fast, but they didn't take care of the plumbing. Things crash and burn, and then they're back to rebuilding with the reliable foundation." For workflow orchestration company Temporal, whose infrastructure predates the current wave of agentic AI, the shift reflects a broader enterprise realization: production AI systems require durable execution, state management, visibility into workflows, and mechanisms to recover when models or downstream systems fail. Agentic AI has supercharged familiar engineering problems. "These patterns aren't necessarily new," Somal said. " AI just supercharges them." Agentic systems introduce additional complexity because they often involve long-running, multi-step processes spanning multiple services, models, APIs, and tools. A single workflow might call several large language models, access retrieval systems, trigger external applications, and manage state over hours or days. The engineering questions, Somal said, often emerge only after deployment. "People will write agents but haven't thought about what happens if the agent crashes," she said. "Am I going to need to run the entire agent flow again?" For enterprises operating under cost constraints, the answer matters. Restarting workflows after failures can multiply inference expenses, increase latency, and create poor customer experiences. Somal compared the current moment to an earlier period in enterprise cloud adoption when organizations went straight to migrating workloads before considering that they needed to redesign underlying architectures if they wanted these workloads to weather the long-term. "This rush to do AI in a world where you haven't even modernized your application reminds me a little bit of that lift-and-shift that happened in the cloud," she said. "Everybody realized you're spending more money on cloud and we haven't gotten value there." Why long-running agents force a new architecture. Enterprise workflows increasingly involve agents executing over long windows, sometimes spanning many hours while interacting with tools and systems. Reliability challenges compound when workflows persist over time, and it impacts both state and memory, two ideas that are often treated interchangeably in AI conversations. State concerns workflow execution. It includes where an agent is in a process, which actions have already completed, and where recovery should resume after failure. Memory or context captures information an agent carries forward across interactions or tasks. "The state of the agent is around what step and what actions have been performed, and if something crashes, where do you want to recover from, versus the context and memory piece," Somal explained. That distinction becomes increasingly important when enterprises begin moving beyond simple chatbot interactions toward longer-running business processes. Somal pointed to a healthcare example involving customer Abridge, where workflows process physician visits through multiple stages, including audio processing, summarization, model calls, and after-visit generation. "There's not just one piece to that flow," Somal said. "Taking videos and slicing that, taking summaries, calling the LLMs, generating the after-visit summary, all of that is being orchestrated." The implication for enterprises is that successful agents increasingly depend on systems that can survive interruptions, coordinate across services, and maintain continuity over time. The rise of the deterministic spine. A useful framework for enterprise AI design is the deterministic spine, Somal said, which is how they think about Temporal's role. "It is denoting the path you want to take," she said. "It is calling the brain, but if the brain doesn't respond, it will call it again. If the brain responds but the next step is going to fail, it will pick up from where that failure happened." In this framing, the language model acts as a probabilistic system producing variable outputs, while orchestration software maintains execution reliability around it. And the concept matters because enterprise systems increasingly require consistency even when models remain non-deterministic. A procurement workflow, healthcare summary, customer support escalation, or compliance process cannot simply fail silently because a model call timed out or an external dependency crashed. "What you care most about is making sure that you can recover and that you're not paying the token tax if something goes wrong," Somal said. Reliability, visibility, and the economics of token spend. As enterprise leaders evaluate AI ROI, cost visibility has become a growing concern. Long-running agents frequently make multiple model calls across complex workflows, which can create opaque spending patterns. Somal described one operational advantage of orchestration as visibility into where costs accumulate. Because workflows are observable step-by-step, teams can see where tokens are being consumed across an agent process. "You've got visibility into that entire flow in a single pane of glass," she said. "You can now see where you're spending the tokens in an agent that is multiple steps and calling multiple different systems." Workflow recovery also shapes cost efficiency. Without durable orchestration, a late-stage failure can force organizations to rerun an entire process from the beginning, including all prior model calls. Somal said systems designed around recovery can resume execution from the point of interruption. "You pick up from where the crash happened," she said. "We save you the cost of running the agent from step one again." Enterprises need to build paved paths and enlist partner expertise. Governance concerns are another emerging pattern as agentic AI takes hold. Rather than adopting fully managed agent systems wholesale, Somal said enterprises increasingly want standardized internal frameworks that provide guardrails while preserving flexibility, and implementing necessary features like governance controls, model selection policies, identity systems, cost management, and observability. "The enterprises are looking at building these paved paths," she said. "Taking something off the shelf is maybe not going to work because there are all of these other requirements." As organizations revisit first-generation deployments, challenges like this increasingly look less like a model problem and more like a systems engineering problem, and Temporal is positioned to help enterprises take this next step in part because for many organizations, it already existed as part of broader modernization programs before AI became a strategic priority. "Temporal is already in the enterprise," Somal said. "Taking that and extending that to AI and agent platforms feels very natural."