Ai Laravel Package

Technical Evaluation

Architecture fit. The package targets a narrow but real problem: an agent session that spans sandbox provisioning, multiple tool/LLM calls, human approvals, and teardown can no longer be safely held open in a request or a single queued job. Durable workflow orchestration is the correct mechanism per the durable-execution guidance, and this package sits precisely at that boundary — it supplies the sandbox lifecycle layer (provision, snapshot, restore, lease, reclaim) on top of a workflow runtime rather than inventing one. For a Laravel application already running agents that execute untrusted code or drive browser sessions, the conceptual fit is high.

The practical fit is unchanged and now more clearly conditional. Release 2.0.0-rc.8 is explicitly a "prerelease artifact for Durable Workflow 2.0 validation" — meaning this package is co-versioned against a parent runtime that is itself pre-GA. The real architectural commitment is to the Durable Workflow 2.0 engine, its persistence schema, its replay determinism rules, and its versioning model, and we would be adopting all of that before its 2.0 line has shipped. With 1 star and 0 dependents, this remains a reference implementation of a pattern, not a proven integration surface. Treat the decision as "adopt a durable execution runtime, with this as an optional accelerator," not "add a Composer dependency" — and note that the runtime we would be adopting is at release-candidate maturity today.

Integration feasibility. Mechanically straightforward and unchanged: composer require, service-provider auto-discovery, publishable config and migrations for workflow/run history plus sandbox records, a registered queue routing boundary for workflow tasks versus activities, and pluggable sandbox providers behind an interface. The effort is not installation; it is restructuring agent code so that every LLM call, tool call, filesystem write, and sandbox operation becomes an activity with a derived idempotency key, while the workflow body stays deterministic and replay-safe. The RC designation adds one practical burden: no changelog, no migration notes, only a source commit hash. Every upgrade must be treated as a source diff review, which shifts cost from installation to ongoing diligence.

Technical risk. High, concentrated in four places:

1. Vendor viability and pre-GA status. Single-digit stars, zero dependents, and now an rc.8 for a 2.0 line that validates against a parent runtime also pre-GA. Eight release candidates is a sign of active work but also of unsettled APIs. The parent package is the load-bearing component; if it stalls or reshapes its persistence schema before GA, we own both.
2. Co-versioning and history compatibility. This release exists to validate against Durable Workflow 2.0 specifically. That implies package and runtime must be upgraded in lockstep, and that in-flight run history written by one RC may not be replayable by the next. Without a documented BC policy, our upgrade window is bounded by how long we are willing to leave runs in flight.
3. Determinism discipline. Replay errors remain the classic adoption failure: branching on now(), rand(), config(), or a fresh Eloquent read inside workflow code produces divergent history and unrecoverable runs in production, usually weeks after launch.
4. Sandbox security and cost. Orchestrating untrusted execution requires credential scoping to activities/providers only, egress control, and hard caps on iterations, wall-clock, and spend. The package can coordinate these; it cannot enforce them for us.

Key questions for the maintainers.

• Is 2.0.0-rc.8 the intended production candidate, and what is the expected path and date to 2.0 GA for both this package and the parent runtime?
• Which sandbox backends are supported (Docker, Firecracker, E2B, browser providers), and is the provider interface stable or pre-1.0?
• Where does durable state live — database, Redis, both — and what are the required drivers and minimum versions for Durable Workflow 2.0?
• What are the PHP and Laravel version constraints for the 2.0 line, and is the parent runtime compatible with our current LTS?
• Does the 2.0 runtime expose deterministic time/randomness/version markers, or must we inject them ourselves?
• Are histories written by earlier 2.0 RCs replayable by rc.8 and later, or does each RC bump require draining in-flight runs? Is there a history schema version field?
• How is history retention handled — continue-as-new, rollover, explicit pruning — and what payload limits apply?
• How are credentials and secrets kept out of durable history in the sandbox provisioning path?
• Is there a documented deprecation/BC policy and release cadence before 2.0 GA, and will RCs ship changelogs?
• Is there a lease/reaper mechanism independent of workflow finalization for resources orphaned by runtime loss?
• Can the package and runtime versions be checked at boot and refused if mismatched, or is skew silent until first replay?

Integration Approach

Stack fit. Assume PHP 8.2+, Laravel 11/12, MySQL or Postgres for durable history, and Redis for the queue. The package will want at least two task queues: one for workflow-task execution (deterministic, latency-sensitive, low concurrency) and one for activities (I/O-heavy, higher concurrency, separate worker pool). Horizon can run both, but they should be distinct supervisors so a slow sandbox call cannot starve workflow-task dispatch. If the team already runs agents synchronously in the request cycle or in single fat jobs, this is a genuine architectural change, not a swap.

Migration path. Greenfield is the sane assumption. If replacing ad-hoc ProvisionSandboxJob → RunAgentJob → TeardownJob chains, do not cut over: run the new workflow path in shadow for one non-critical use case, comparing outcomes and lifecycle timings against the existing job chain for two to four weeks. Critically, wrap the package behind an internal port — AgentSandboxOrchestrator with our own value objects — so the workflow engine and sandbox provider are both swappable if the dependency is abandoned or its schema shifts before GA.

Compatibility. Pin exact versions of both durable-workflow/ai and its parent runtime, and pin them together — this RC is defined by its parent-runtime pairing, so a loose constraint on either side is a live hazard. Record the source commit hash (b0a5e4a5c192974a1ed4cc75d77be07ada94ffba) alongside the version in your dependency ledger; it is currently the only traceable identifier in the release. Validate the workflow/task payload schema and history schema against a staging database restored from production before any upgrade, and capture a fixture set of representative run histories that you replay on every RC bump. Confirm queue driver semantics (visibility timeouts, retry behavior) match what the runtime expects; a mismatched Redis queue configuration produces duplicate workflow-task dispatch that looks like a replay bug. Confirm no conflict with existing migrations on shared tables — publish and review the migration files before running them.

Sequencing.

1. Read the Durable Workflow 2.0 documentation and skill guidance first; confirm the runtime is mature enough to own, and get a GA commitment in writing. If it is not forthcoming, stop here and build a database state machine instead.
2. Gate the adoption decision on 2.0 GA, or accept RC risk explicitly with a named owner, a drain-before-upgrade policy, and a rollback plan. Do not let an RC reach production by attrition.
3. Spike: one workflow, one sandbox provider, one activity — prove that a run survives a worker kill mid-sandbox and resumes correctly. This single test de-risks the entire adoption.
4. Define the process contract explicitly: business key, invariants, idempotency key derivation, timeouts at step/attempt/process level, terminal states.
5. Build the internal port and adapter; make the package and the runtime versions an implementation detail behind a single boundary.
6. Add approvals/cancellation as signals and updates with explicit timeout and rejection paths, plus budget and iteration caps.
7. Add the independent lease reaper and validate it by killing workers while sandboxes are live.
8. Standing obligation from this release onward: on every RC bump, diff the source, re-run the replay fixtures, and only then deploy. Roll out behind a feature flag to one tenant or one agent use case; expand only after replay tests pass against captured production histories.

Operational Impact

Maintenance. We inherit two pre-GA packages from a small organization with no adoption base, and the release we are evaluating ships without a changelog or migration notes. Budget for the possibility of vendoring or forking within twelve months, and for reading source diffs at each RC. Subscribe to releases, pin versions, log the source commit for every deployment, and keep a written upgrade procedure that includes draining or tolerating in-flight runs plus replay-testing representative histories. The internal port adapter is the insurance policy — it caps the blast radius of abandonment or schema churn at one file.

Support. Community-only, no SLA. Escalation is ourselves. This is acceptable for an internal agent platform where a stalled run is recoverable; it is not acceptable for anything customer-facing without an internal owner named in advance. The RC status raises the bar on that ownership: someone must be accountable for tracking the 2.0 line to GA and for each upgrade decision.

Scaling. Three independent ceilings: workflow-task throughput, activity concurrency, and sandbox provider quota. All three need explicit limits — durable fan-out will happily exhaust a downstream sandbox API just as fast as naive concurrency. Budget caps (iterations, elapsed time, spend per run) are mandatory, not optional; a durable infinite loop is still an infinite loop. Plan for history growth: long-lived agent runs with many messages require continue-as-new or an equivalent rollover, and large transcripts must live in object storage with an immutable reference plus integrity metadata recorded in history, not in the history itself. Record the package and runtime version on every run so that a failure can be attributed to a specific RC after the fact.

Failure modes to instrument and alert on.

• Replay divergence after deployment or after an RC upgrade — nondeterministic code or a changed history schema meets old history. Detect via replay-error counters segmented by package version; prevent via replay tests in CI against captured histories.
• Version skew between durable-workflow/ai and the Durable Workflow runtime, which the release notes make explicit as a pairing. Detect via a boot-time version assertion in the service provider adapter and an alert on mismatch across the worker fleet.
• Orphaned sandboxes after host loss or termination — workflow finally cleanup does not run. Requires the external lease expiry/reconciler, with an alert on leases past their deadline.
• Duplicate side effects — double-charged sandbox hours, duplicate tool invocations, repeated notifications. Mitigate with derived idempotency keys, provider idempotency tokens, and an application receipt table where the provider has none.
• Stalled waits — an approval or callback never arrives. Alert on wait age exceeding business deadline, not on run duration.
• Credential leakage — secrets or sandbox tokens recorded in durable history. Enforce by scoping credentials to activities and reviewing run payloads in staging.
• Queue latency and retry exhaustion on the activity pool, which presents to users as a hung agent rather than an outage.

Operate runs as a product surface: expose stable workflow/run identity, package/runtime version, business correlation key, current phase, pending timer/message/activity, attempt count, last failure, next retry time, and cancellation/compensation outcome in an internal admin view before going to production. Do not debug by editing runtime persistence.

Ramp-up. A senior engineer needs roughly one to two weeks to internalize replay discipline, effect idempotency, and compensation modeling, and the team needs a code-review checklist that blocks nondeterministic constructs inside workflow code. The failure mode is not a slow ramp — it is a fast ramp followed by subtle, production-only replay errors. Three guardrails make the difference: the worker-kill resume spike in the first week, replay tests in CI before the first production run, and a version-pinning/upgrade ritual that is followed from the first RC onward rather than invented after the first incident.