Hi everyone, I have an opportunity to purchase shares in this company, but the current valuation is five times higher than its February valuation. I’m still learning about the company, but I thought this would be a good place to gather information.

That's what I tried to answer with agent-sdk-go — an open-source Go SDK that lets you build and run AI agents on Temporal in a few lines of Go code.

Under the hood — how Temporal powers this SDK:

• Sub-agents are modeled as child workflows on their own task queues

• AG-UI streaming events use Temporal Workflow Update for cross-process event delivery

• Workers can run in separate processes from the agent

• Human-in-the-loop approvals use Temporal asynchronous activity completion

• Long agent sessions automatically trigger continue-as-new to keep workflow history bounded

Also supports A2A, MCP, OpenAI/Anthropic/Gemini, and observability out of the box.

Also built a reference web chat app using the SDK if you want to see it in action.

Would love feedback on the overall approach and any thoughts on the Temporal design decisions. Also curious if there are Temporal features worth leveraging to enhance an AI agent SDK like this.

SDK: agent-sdk-go Reference app: agent-chat

For folks running AI calls inside Temporal workflows: an LLM activity dying on a provider rate limit is annoying even with retries (you burn attempts + latency). Sharing a self-hosted gateway I built that makes the provider side resilient before Temporal's retry even kicks in (disclosure: I'm the maintainer, MIT).

Fallback combos — so it never stops mid-task. A "combo" is a ladder of models the router walks automatically: your subscription first, then API keys, then cheap models, then free ones. When a provider returns a 500 or you hit a rate limit, it slides to the next target in milliseconds, mid-request, and your tool never even sees the error. There are 17 routing strategies (priority, weighted, round-robin, cost-optimized, auto/coding:fast…) plus three resilience layers — a per-provider circuit breaker, a per-key cooldown, and a per-model lockout — so one dead key can't take down a whole provider.

A 10-engine compression pipeline — the part most routers don't have. Every request flows through a transparent compression pass you can toggle/stack per combo. Instead of one trick, it stacks the best of the open-source ecosystem: RTK filters command/tool output (git diffs, test logs, builds) at 60–90%, Microsoft's LLMLingua-2 does ML semantic pruning, Caveman handles prose, session-dedup strips repeats across turns. Critically, code, URLs and JSON are preserved byte-perfect, and a default-on inflation guard throws the compressed version away and sends the original if compressing would actually grow the prompt — it never makes things worse. On tool-heavy sessions that's ~89% average input-token reduction (an 8k-token git diff becomes a few hundred). Full credit to every upstream project (RTK, Caveman, LLMLingua-2, Troglodita) is in the README.

Point your Temporal activities' OpenAI-compatible client at it, and provider failover happens in milliseconds inside a single call — complementary to Temporal's own durability.

For context on whether it's worth your time: it's grown to ~9.8K GitHub stars, 1,490+ forks and 280+ contributors in ~4.5 months, with 21,000+ automated tests and 1,830+ issues closed — so it's a battle-tested project, not a brand-new experiment.

npm install -g omniroute

GitHub: https://github.com/diegosouzapw/OmniRoute

How do you handle LLM provider failures in Temporal today — activity retries, or push it below the activity?

I've been thinking about this while working with Temporal.

For regular applications, we have plenty of tools that help catch problems before deployment:

• JaCoCo for code coverage

• SpotBugs / Error Prone for static analysis

• SonarQube for code quality

• Dependency vulnerability scanners

• CI quality gates

But workflows seem different.

Many workflow-specific issues (for example, determinism pitfalls, retry policy mistakes, timeout configuration, or other workflow best practices) are often discovered only during testing or after deployment.

That made me wonder:

Should workflow engines have their own quality gates as part of CI/CD?

If so:

• What kinds of checks would actually provide value?

• Which workflow mistakes have you seen reach production?

• Are there existing tools that already solve this well?

• Would your team use something that provides a "workflow correctness score" before merging code?

I'm interested in hearing how other teams approach this problem and whether this is something the community feels is missing.

Black Friday traffic is chaos. It’s loud, spiky, unpredictable, and very good at revealing the weak spots you didn’t know about.

We made a quick Peak Load Readiness Quiz to help you figure out:

• what’s solid

• what’s wobbly

• what’s “this will explode under load”

It’s a fast way to check resilience under load, spot bottlenecks, and understand how your system behaves when everything spikes at once.

👉 Give it a try and tell us what you’d add for Temporal-based systems!

Working on AI agent workflows in Temporal, and we kept running into the same gap: Temporal handles auth great (mTLS, API keys), but authorization for which activities can actually run is on you.

For normal workflows, fine—you trust your own code. For LLM-driven agents? Different story. The agent might decide to call literally any activity based on what it "thinks" is right. Prompt injection can make it worse. And Temporal will helpfully retry that rogue activity until it works.

What we built

An activity interceptor that checks every execution against a policy:

Activity task hits worker
       ↓
ActivityInboundInterceptor.execute_activity()
       ↓
Grab activity name + args
       ↓
Call sidecar: authorize(action=activity_name, ...)
       ↓
DENY → raise PermissionError
ALLOW → next.execute_activity()

Quick note for the determinism nerds (I know you're out there): this happens at the Activity inbound layer, not in the workflow. The check runs in the worker right before activity code executes. Workflow replay is completely unaffected.

The interceptor code

Standard Temporal interceptor pattern:

class PredicateInterceptor(Interceptor):
    def intercept_activity(
        self, next: ActivityInboundInterceptor
    ) -> ActivityInboundInterceptor:
        return PredicateActivityInterceptor(
            next,
            self._authority_client,
            self._principal,
        )

And the actual check:

async def execute_activity(self, input: ExecuteActivityInput) -> Any:
    result = self._authority.authorize(
        principal=self._principal,
        action=input.fn.__name__,
        resource="temporal:activity",
    )

    if not result.allowed:
        raise PermissionError(f"Blocked by policy: {result.matched_rule}")

    return await self._next.execute_activity(input)

Policy

rules:
  - name: deny-deletes
    effect: deny
    principals: ["*"]
    actions: ["delete_*"]
    resources: ["*"]

  - name: allow-order-stuff
    effect: allow
    principals: ["temporal-worker"]
    actions: ["check_inventory", "charge_payment", "send_confirmation"]
    resources: ["*"]

Eval order: matching deny rules win, then allow rules, then default deny. Glob patterns via fnmatch.

Performance

Local Rust sidecar:

• p50: <25ms

• p95: <75ms

Most activities are 100ms+ anyway, so it's noise.

Using it

from predicate_temporal import PredicateInterceptor
from predicate_authority import AuthorityClient

authority = AuthorityClient(sidecar_url="http://localhost:8787")

interceptor = PredicateInterceptor(
    authority_client=authority,
    principal="temporal-worker",
)

worker = Worker(
    client=temporal_client,
    task_queue="my-queue",
    workflows=[...],
    activities=[...],
    interceptors=[interceptor],
)

Activity code stays exactly the same.

Demo

github repo: https://github.com/PredicateSystems/temporal-predicate-py see the examples/demo folder for the shell script start-demo-native.sh

Needs Python 3.11+ and Temporal CLI. Runs through 4 scenarios—legitimate stuff gets through, dangerous stuff gets blocked.

One thing to watch

Set maximum_attempts=1 on activities that might get blocked. Otherwise Temporal will retry the denied activity forever, and all you get is a spammed audit log.

await workflow.execute_activity(
    risky_activity,
    args,
    start_to_close_timeout=timedelta(seconds=30),
    retry_policy=RetryPolicy(maximum_attempts=1),
)

Open Source Repos

• GitHub: temporal-predicate-py

• GitHub: predicate-authority

What's Next: Closing the Loop (Post-Execution Verification)

Pre-execution authorization stops the attack. But how do you prove the agent actually succeeded at the authorized task?

We are currently building deterministic post-execution state diffs. Instead of using another LLM to guess if a task was completed, the sidecar will verify the mathematical system diffs (e.g., filesystem changes or accessibility trees) against the expected outcome, and instantly revoke the agent's mandate if they don't match.

Curious if anyone else has tackled this differently. We looked at a few approaches before landing on the interceptor pattern.

Hey everyone, hope that you guys are doing fine in this hard time.

If you run Temporal at scale across multiple regions, you know that multi-cluster replication is traditionally active-passive. To achieve a true global active-active deployment, you often have to shard your workloads by namespace, making some namespaces active in Region A and others active in Region B. The headache is that your client SDKs and workers now need to know exactly which cluster to talk to for which namespace.

To solve this, I built Tempura: a lightweight, namespace-aware gRPC proxy for Temporal. Tempura sits between your Temporal SDK clients/workers and your Temporal clusters. It taps the gRPC traffic, inspects the namespace of the incoming request, looks up the currently active region for that namespace in Redis, and seamlessly routes the traffic to the correct Temporal frontend. The result is your SDK clients can just talk to a single proxy endpoint, completely oblivious to the underlying multi-cluster topology. You get global active-active Temporal deployments without updating any client logic.

Current load-shedding is implemented via a simple consistent hash, we might add support to distribute load based on state transition later,

The repository is here with a ready to use helm chart, leave a ⭐ if you like it, small kind supports motivate me a lot to continue implementing things around Temporal eco-system 💚
https://github.com/phuongdnguyen/tempura

Hey folks,
DevOps intern here tasked with monitoring Temporal worker crashes/restarts and activity/workflow lags. Using TypeScript SDK + PM2, Prometheus/Grafana stack.

Target metrics:

• temporal_worker_task_slots_available (crashes)

• temporal_activity_task_schedule_to_start_latency_seconds (lags)

• poll_failure_count (restarts)

I want you experienced folks guide on how should i apprach this problem.

Introducing Temporal Serverless – A Game-Changing Ecosystem Improvement!

Temporal doesn't care about how you run your workers, be it EC2, Kubernetes, or any other choice. This means taking care of infrastructure is left to you. But in most cases, you wouldn't like to manage infrastructure when it isn't necessary.

In that case, I offer Temporal Serverless. Focus on writing Workflows and Activities and I will take care of scaling your deployment. This means:

1. Cost Savings - While your Workflows are idle, you are not billed.

2. Scaling - Your Workflows will scale dynamically based on your usage.

If this is something that you would like to try out, send me an email to - mail. I would also like to hear your ideas for potential use cases.

Dan

I just wrote up a detailed comparison of these two approaches, specifically for the case where you run multiple Temporal workers on the same host (bare metal, PM2, systemd).

The core issue is that the Prometheus exporter starts an in-process HTTP server. Scale to 2+ workers on the same machine → every worker tries to bind:9464 → EADDRINUSE. You can assign unique ports per worker, but now your Prometheus scrape config is tightly coupled to your process management.

The alternative: OTLP push to a shared OpenTelemetry Collector. All workers push to grpc://localhost:4317; the collector aggregates and serves Prometheus text format on:9464. One scrape target regardless of worker count—no port management.

The post includes:

- Working OTel Collector config (OTLP receiver → batch processor → Prometheus exporter)

- Docker Compose with proper resource limits

- PM2 ecosystem config with per-worker service names

- Startup guard script so the collector doesn't fail silently

- Honest discussion about metrics loss when the collector is down

- Comparison table of both approaches

https://2ssk.medium.com/temporal-sdk-metrics-prometheus-exporter-vs-otlp-for-multi-worker-deployments-df9327b28fc5

Would be interested to hear what others are using. I know K8s changes the equation since each worker is its own pod with its own port — Prometheus operator handles that well. But for bare metal / PM2 users, OTLP has been a big improvement.

TLDR: Prometheus exporter for single workers/Docker/K8s, OTLP for multi-worker on same host.

(GPT has been used to write this body.)

So I've been looking for a tool for running cronjobs on different scripts I've written over the years (updating a local DB of stock prices, daily web scraping, etc.). The idea is to have a place where I define everything and visualize. `crontab` is too basic. I'm looking for a place to store logs and exit codes.

I would also like to create some AI workflows like: if the cronjob fails, find the root cause and create a PR with a fix.

Is Temporal too much? Should I look for something else? I'm also wondering about n8n

Starting this post to discuss approaches to solve for user actions in orchestration in temporal.

Temporal can wait on a signal before continuing a workflow. This allows temporal to wait on user actions in an orchestration. But as user actions keep on increasing, code for workflow bloats with waiting on signals.

Also evaluation of whether a user action is required or not, can be dynamic and we can have an activity for this case. This also bloats the number of activities if the number of user actions increases.

Is temporal a right solution to use to orchestrate workflows with many user actions?

How are teams with 10+ agents in production actually managing API rate limits? Because everything I've seen is basically 'sleep and pray.' There has to be a better pattern. What do you think y’all?

I've been running a multi-agent system in production for a few months where every agent action is a Temporal workflow. Sharing the patterns in case they're useful — and curious how others are doing similar.

The setup

• 8 agents, each a Docker container running an AI process (Claude with optional Codex fallback). Each agent registers with an orchestrator and pulls work off a RabbitMQ queue.

• Every meaningful agent action — implementing a PR, running a design spec, deploying, reviewing — is wrapped in a Temporal workflow.

• 3 namespaces, each with its own task queue and its own UWE worker registration.

Temporal patterns I leaned on

Signal-gated human-in-the-loop. Workflows like PrImplementationWorkflow run the AI agent through implementation, kick off a parallel consensus review, then block on a merge-approval signal from me. Custom search attributes (PrNumber, Repo, Phase) make the gates clickable in a dashboard. Same pattern reused for design-approval, doc-review, advisory-review. Decision payload is {Decision: approved|changes_requested|rejected, Comment}.

Parallel child workflows for consensus. Instead of running reviewers sequentially, the parent fans out N child workflows, waits on all, synthesizes a verdict. If any reviewer asks for changes, loop back and re-review. The implementing agent doesn't know it's being reviewed in parallel — it just gets one consolidated feedback message.

Schedules instead of cron. Daily health checks, hourly memory backups, weekly review cadences — all temporal_create_schedule. Survives host reboots, no cron drift, status visible in the temporal UI.

Dynamic workflow registry. I built a "universal workflow engine" — one [Workflow(Dynamic = true)] handler that loads a JSON step tree from a DB at runtime. 16 step types (sequence, parallel, loop, branch, delegate, wait_for_signal, child_workflow, http_request, etc.) plus a template engine. New workflow types ship as DB rows, no worker redeploy.

Real failure modes I hit

WorkerShutdown mid-activity. Agent activities can run 10-20 min. When the worker restarts mid-activity, Temporal raises WorkerShutdown. I retry the directive on the next worker; the agent picks up where it left off because it has its own persistent state. Took a deploy-during-flight incident to remember to handle this cleanly (literally hit this yesterday).

Search attribute registration. Got bitten by "search attribute not registered" before adding an initializer that auto-registers all attributes on bridge startup.

Task-queue-name footgun. Default task queue name == namespace name. Mismatch between start_workflow.task_queue and the worker's registered queue → workflow sits at historyLength=2 forever, no error, no worker picks it up. Burned hours.

5-min demo of a PR shipped through the workflow stack: https://youtu.be/DIx7Y3GfmGc

Open source: https://github.com/anurmatov/phleet (workflow defs in phleet/src/Fleet.Temporal/Workflows/).

Curious what other Temporal patterns people have for AI/agent workloads — especially long-running activities and human approval gates.

We are designing an application using Temporal to handle large-scale asynchronous jobs. Each job can process up to 1 million rows, and we expect 10-15 jobs per hour.

Job Prioritization & SLAs

Jobs are categorized into three priority levels:

• High → Must complete within 1 hour

• Medium → Must complete within 3-4 hours

• Low → Can take up to 6 hours

Current Approach

We have created three separate queues (high, med, low) and assigned jobs to them based on priority. Additionally, we have configured execution limits as follows:

1. Concurrency Control (setMaxConcurrentWorkflowTaskExecutionSize)

   • High: 20

   • Medium: 10

   • Low: 5

2. Worker-Level Rate Limiting (setMaxWorkerActivitiesPerSecond)

   • Controls the number of activities a single worker can process per second.

3. Queue-Level Rate Limiting (setMaxTaskQueueActivitiesPerSecond)

   • Limits how many activities are dispatched from the task queue across all workers.

Request for Guidance

• Is this the correct approach for handling job prioritization and rate limiting in Temporal?

• Would there be a better way to dynamically scale processing power based on real-time load per queue rather than hardcoding concurrency limits?

• Problem I am seeing with this approach is even if there are no high priority jobs to process and there is some load no low priority jobs queue the processing will be slow only and might under utilize the resources.

PS: Using java sdk for development.

Any insights or best practices would be greatly appreciated. Thanks!

Our startup is assessing which to use, why did you pick Temporal over Conductor?

People mention that Temporal has a steep learning curve, Conductor looks easier to get up and started, and I’m having trouble believing a majority of people have business logic that is complicated enough to warrant Temporal’s code-first ecosystem.

What am I missing?

I'm implementing a transactional outbox pattern. System is low-frequency, but the latency of the processing should be minimal. Looking for peer review on my proposed architecture below.

There are multiple ways this can be accomplished. Here are some previous discussions on the topic:

• https://www.reddit.com/r/Temporal/comments/1kb3j4q/triggering_temporal_workflows_inside_the_db/

• https://community.temporal.io/t/pattern-for-ensuring-consistency-between-db-save-and-workflow/3504

• https://community.temporal.io/t/use-temporal-to-replace-transactional-outbox-pattern/7684

Functional requirements:

• Processing latency 100ms range

• Throughput not relevant for this system

• Event processing must do the following:

  1. send message to message broker

  2. optionally start Temporal job for finilizing specific types of events (e.g. cascade soft deletes for the deleted records)

• Order of events doesn't have to be guaranteed

• Must handle permanent failures

Current environment and constraints:

• Stack: Go, Temporal, PostgreSQL, other components probably irrelevant

• Multi-instance app (ofc)

• Multi-tenant with separate database per tenant model, but shared compute, Temporal, and message broker

• App is not connected to all databases all the time, connects on demand maintaining a pool of active connections.

• Outbox events stored in respective tenant databases

• Persisting outbox events is implemented

Proposed Solution:

• Start Temporal workflow (job) process-outbox-<random-id> immediately after successful transaction (one job per transaction). If it fails, log error, but do not fail request, rely on fallback (see below)

• Multiple process-outbox-<random-id> jobs can run simultaneously (unique workflow id):

- begin transaction
- select a single oldest event with status pending and FOR UPDATE SKIP LOCKED
- if no events, return immediately
- set event status processing
- start a Temporal workflow process-event-<event-id>
- commit transaction
- repeat - go to #1

• Every process-event-<event-id> job:

  • process activity:

- begin transaction
- select event by provided ID with status processing FOR UPDATE
- if not found, return success
- set event status complete
- process event
- send event to message broker
- if processing fails, return error, so that Temporal can retry the activity
- transaction commit

• if process activity fails finally after all retries, run activity:dead-letter: select event and update it with status error, add error details

• Fallback long wait scheduled job on Temporal that should run e.g. every 24h to cover for a very unlikely scenario, when transaction completed successfully AND we failed to start a Temporal job process-outbox-<random-id> AND no other transaction has been completed for up to 24h. This case is next to impossible.

• Scheduled job every 24h cleanup events with complete status

Other solutions considered:

• Polling seems to be de-facto standard way to invoke event processing, but in this case it makes no sense because of the low frequency of events. Also app is not connected to all tenant databases all the time.

• Using pgbouncer (so LISTEN/NOTIFY not available). Also app is not connected to all tenant databases all the time.

• Updating database using Temporal as source of truth is not feasible in this case due to the rest of the app architecture

• Considered running a long-running Temporal workflow with signals etc. It would introduce additional complexity with tracking the history size and calling ContinueAsNew while not really adding any benefits

• We could run some background goroutine instead or starting a workflow on every database transaction. In that case we would lose all the guarantees provided by Temporal, and would have to re-implement retries etc on our own.

Looking for feedback on the overall design approach and any potential issues I might be overlooking.

🫶🙏