Depthnet Laravel Package

Technical Evaluation

What this release actually is. The 1.0.4 notes are written as a feature narrative for the 1.0.x line rather than a changelog. Three capability clusters ship or mature: Wake (scheduler-driven self-scheduled agent invocations), Voice (per-preset STT/TTS providers with browser and OpenAI-compatible/local backends), and Mode (agent self-editing of its own prompt with versioning, diff, and revert). For a Laravel/PHP consumer, the relevant question is not whether the features are interesting — they are — but how much of the host application's runtime, queue, scheduler, storage, and secrets surface they colonize.

Architecture fit.

• Wake is the highest-leverage and highest-coupling feature. It implies persistent scheduled records, a dispatch path that runs outside the request/response loop, and recomputation of recurring schedules after successful dispatch. In a Laravel context this maps naturally onto the scheduler + queue primitives (schedule:run via cron, queued jobs, failed_jobs, Horizon), but the package's timing grammar is richer than Laravel's native cron-only scheduling: relative (+2h), absolute timestamps, daily wall-clock (14:30), intervals (every 6h), full cron, plus a subjective pulse unit (p850, +20p) that has no framework analogue. Expect the package to own its own tick loop and due-record query rather than delegating to $schedule->command() per wake. That is the right design for scale, but it means one more always-on worker class in the deployment.
• Voice is a clean provider-abstraction story and the least invasive: per-preset capability config alongside vision/embedding suggests an existing capability registry we would extend, not rebuild. The "local by default" posture (faster-whisper + Piper in a bundled voice-service container) is a strong data-residency property and a real operational addition — it moves part of the deploy from "PHP app + DB + Redis" to "PHP app + DB + Redis + GPU/CPU inference container."
• Mode is the most governance-sensitive. Self-editing is off by default and gated behind versioning, which is the correct shape, but it introduces write access from the agent to its own prompt substrate. That is an audit, review, and rollback requirement on our side, not just a feature flag.

Integration feasibility. High for Voice (config + one container + admin config surface). Medium for Wake (new scheduled workload, new persistence, new failure semantics, timezone and DST correctness to verify). Medium-to-low for Mode (needs our review workflow and diff tooling wired to however versions are stored; needs a policy on who may revert). Nothing here appears to require forking the package, but Wake and Mode both assume admin UI surfaces ("Admin → Wakes", "Admin → Capabilities") that we should confirm are package-provided rather than host-provided.

Technical risk.

• At-least-once delivery is stated explicitly. Recurring wakes recompute after successful dispatch so a crashed worker re-fires rather than drops. The corollary is duplicate execution, and the notes do not describe a dedupe key, idempotency token, or dispatch ledger. Any wake whose effect is not idempotent (sending a message, charging a card, calling an external API) is a duplicate-action risk we must design around.
• Prompt drift. The notes are admirably candid that self-editing introduces cumulative drift. Versioning, diff, revert, and optional required-annotation are mitigations, not preventions. This is an ongoing evaluation cost, and it lands on whoever owns agent quality.
• Silent quality regressions from voice provider mixing. STT/TTS are independently selectable, which is powerful and also means many configurations to validate. Transcription quality differences between browser and local backends are material (the notes claim roughly 2x realtime on a mid-range CPU for local, and Firefox support only server-side) — support burden follows the matrix.
• Release-notes opacity. There is no explicit breaking-change, deprecation, or upgrade-path section for 1.0.4 specifically. The notes reference v1.0.0 as the milestone; we cannot tell from this document alone what changed between 1.0.0 and 1.0.4. That must be resolved before we pin.
• Cron granularity. Sub-minute or pulse-based schedules interacting with a one-minute framework tick is an area where semantics can quietly differ from operator expectation.

Key questions for the maintainers.

1. What is the supported Laravel and PHP version matrix for 1.0.4, and is there a documented 1.0.0 → 1.0.4 changelog with breaking changes called out?
2. How are wake records stored and queried — Eloquent model with published migrations, or opaque package storage? Are they multi-tenant scoped?
3. Is there an idempotency key or dedupe window on wake dispatch? What is the documented behavior for a wake that fails repeatedly (retry budget, dead-letter, alerting)?
4. Timezone and DST semantics for absolute and daily wakes — stored UTC, evaluated in tenant timezone, or both?
5. Do Wake and Mode require the package's admin UI, or are there headless APIs/events we can bind to our own admin surfaces?
6. What is the audio retention and storage policy for Voice (driver, TTL, encryption at rest)? Is raw audio persisted by default?
7. For Mode: what is the storage model for prompt versions, can we enforce required-annotation org-wide, and is there an approval gate before a self-edit takes effect?
8. Licensing and support posture for the bundled voice-service container, and its resource footprint (CPU/RAM/VRAM minimums).

Integration Approach

Stack fit. The package sits in the Laravel "agent runtime" slot: service provider registration, publishable config, migrations for presets/wakes/prompt versions, an admin surface, queue workers doing the heavy lifting, and the scheduler as the heartbeat. All three feature clusters lean on capabilities we already run in production (Redis queues, Horizon, cron-driven schedule:run, object storage, a secrets manager). Voice's OpenAI-compatible provider path is a genuine plus — it means we can point at the bundled container, at a hosted endpoint, or at an internal gateway without code changes, which is exactly the abstraction a TPM wants when procurement and data-residency constraints differ per environment.

Migration path.

1. Pin and verify. Start on 1.0.4 in a staging branch. Resolve the 1.0.0→1.0.4 changelog question first; there is no prior assessment to diff against, so this is a greenfield evaluation, not an upgrade.
2. Land Voice first. Lowest blast radius, immediately demoable, and it validates the capability-config surface that Wake and Mode also depend on. Configure per-preset STT/TTS in staging; run the browser/local matrix across the five shipped languages.
3. Then Wake, in a sandbox preset. Enable wakes for a single non-production preset with a hard cap on concurrent scheduled wakes. Exercise each timing grammar form, then deliberately kill a worker mid-dispatch to observe at-least-once behavior and confirm our idempotency wrapper holds.
4. Then Mode with self-editing off. Adopt versioning, diff, and revert for human edits only. Turn on agent self-editing for one internal preset with required-annotation enforced, and only after we have a review cadence and a named owner for drift review.
5. Then expose user-designed wakes in Admin once we have per-tenant quotas, since this is the first surface where non-engineers can create recurring background load.

Compatibility. Two dimensions matter. Framework: Laravel/PHP version floor, queue driver assumptions (database queue will behave badly under wake fan-out; Redis/SQS required in practice), and whether the admin surface depends on a specific frontend stack or Livewire/Inertia version. Provider: the OpenAI-compatible audio contract is a de facto surface — confirm which endpoints and payload shapes are exercised so we can swap backends without surprise. Also confirm behavior on the Browser STT path for users on Firefox (server-side only, per the notes) so the UX degradation is documented rather than discovered.

Sequencing and scope. Treat this as three independently shippable increments, not one release. Voice and Wake can go to production on separate timelines; Mode should trail both, because its value depends on Wake (an agent that can edit itself probably wants to schedule its own review) and its risk depends on organizational readiness for AI-authored prompt changes. Budget explicitly for the voice-service container in the platform's deployment topology before committing to "local by default."

Operational Impact

Maintenance. Three new recurring maintenance obligations: (1) wake schedule hygiene — orphaned wakes for deleted presets, stale recurring wakes, and calendar growth; (2) prompt version history growth with a retention policy, since every agent self-edit and every admin edit is snapshotted; (3) voice model artifacts and the bundled container image lifecycle, including language catalog updates. None is onerous individually; together they add a genuine surface to the on-call rotation. Version churn through the 0.x line was evidently high enough that maintainers thank testers for "observations from their own experiments" — expect continued fast iteration and pin exactly.

Support. Expect a spike in configuration-shaped tickets rather than defect tickets: which STT/TTS combination to pick, why Firefox behaves differently, why a wake did not fire at the expected wall-clock time, why an agent "changed its mind" (i.e., drifted its prompt). The Mode feature in particular converts a product-support question into a forensic one — diff and revert tooling must be reachable by support staff, not only by the agent. Write the runbooks before enabling user-designed wakes.

Scaling.

• Wake scales as a function of scheduled-record count and dispatch rate, not request volume. The due-record query needs an index on fire-time; the worker pool needs to be sized for bursty minute boundaries (many 14:30 daily wakes firing simultaneously). Recurring recompute-after-dispatch means the write path is on the hot path.
• Voice scales on compute, not on PHP. Local STT at roughly 2x realtime on a mid-range CPU gives usable headroom for conversational use but not for batch transcription of long recordings; concurrency is bounded by container capacity, and this is the first place a queue backlog will become user-visible latency. Plan capacity and a fallback provider.
• Mode scales cheaply (small text blobs) but its review cost scales linearly with agent count and edit frequency — that is a human scaling problem, and the optional required-annotation is the main lever for keeping it tractable.

Failure modes to design for.

• Duplicate wake execution from at-least-once delivery — requires idempotent wake handlers; the highest-severity item in this release.
• Dropped or delayed wakes from a stalled scheduler or saturated queue — the agent silently "sleeps through" its appointment. Needs a lag/liveness alert on scheduled-vs-actual fire time.
• Scheduler outage during a recurring wake's recompute window — verify the schedule does not silently degenerate to a shorter or longer interval.
• Voice provider outage or container OOM — degrade to text, do not fail the turn; the browser/local split makes a graceful fallback straightforward if we build it.
• Prompt drift accumulating below the threshold of any single review — the notes' own framing. Mitigation is process: periodic diff review against a calibrated baseline, revert authority with a named owner, and required-annotation enforced.
• Runaway self-scheduling — an agent creating wakes faster than they fire, or a user-designed wake with a tight cron. Needs per-preset and per-tenant caps on active wakes and minimum intervals.

Ramp-up. Estimate roughly: one engineer-week to land Voice end-to-end including the container and provider matrix in staging; one to two engineer-weeks for Wake including idempotency, timezone/DST verification, and failure-injection testing; Mode is a half-week of engineering plus an indefinite ongoing review commitment that should be staffed deliberately rather than absorbed. Platform/DevOps effort for the voice-service container (image pinning, resource limits, health checks, model updates) is real and should be scoped with the platform team before Voice is promised to stakeholders.

Recommendation. Adopt in stages: Voice (production-ready, low risk), Wake (adopt with an idempotency wrapper and quota caps — the strategic feature, and the one that finally makes long-lived agents economically sane by letting them sleep), Mode (adopt versioning immediately as governance infrastructure; enable self-editing only for a controlled pilot with an owner). Resolve the changelog and Laravel-version questions before pinning, and do not expose user-designed wakes to non-engineers without per-tenant quotas.