Depthnet Laravel Package

Product Decisions This Supports

Build vs. buy for agent runtime infrastructure. The v1.0.4 release pushes three non-trivial capabilities — scheduler-driven temporal agency, first-class STT/TTS capability slots, and versioned prompt self-authorship — out of "custom glue we'd have to write" and into the package. Each of those is a credible multi-sprint build on its own (a durable job scheduler with agent-facing grammar, a dual-provider audio abstraction, and a diff/revert/annotation layer over prompt state). This release is the moment to re-run the build-vs-buy comparison rather than assume the earlier verdict still holds.

Roadmap sequencing for persistent agents. The "memo → wake → goal" continuum is a useful product framing to adopt as-is: it tells you which temporal capability to expose to users next. If you already ship memo-style short-cycle behavior, wake scheduling is the natural next increment and it's now available rather than speculative. Any roadmap item phrased as "agent should follow up later," "agent should run a daily routine," or "agent should nudge the user tomorrow" is now a configuration task, not a feature project.

Feature bets that were previously blocked on privacy posture. Local-by-default STT/TTS (bundled faster-whisper + Piper) means voice can go on the roadmap for customers who would never accept audio leaving the host — regulated, healthcare-adjacent, EU-resident, or on-prem enterprise segments. That is a segment-expansion decision, not just an engineering one. Conversely, the browser-provider option lets you ship voice to low-friction self-serve users with zero key management, so you can price and package the two paths differently.

Multi-channel voice as a product surface. The notes are explicit that server-side providers work outside the browser, so a voice message arriving from any channel can be transcribed into agent input and replies synthesized back. That reframes voice from "a web widget" to "a channel capability," which affects channel strategy (phone, messaging apps, embedded) and where you invest next.

Governance and trust as a shippable feature, not a policy doc. Mode's version history, diff, revert, and optional required-annotation are the artifacts you need to answer enterprise security review questions about an agent that can rewrite its own instructions. This unlocks a sales conversation that was previously a hard no. Note the deliberate safeguard — full rewrite is off by default — which gives you a defensible default configuration to ship and a documented escalation path for power users.

Admin-surface investment. "Admin → Wakes" and "Admin → Capabilities" mean non-engineers can program scheduled agent behavior and pick providers. That changes who your buyer's day-to-day operator is: support/ops staff can now own agent scheduling and voice config without a deploy. Factor admin UX quality into your evaluation, since it is now load-bearing for the product.

Evidence caveat. This assessment is derived from release notes alone; there is no prior evaluation, no code review, no benchmark data, and no license or maintenance-signal information in hand. Treat the capability claims as directionally accurate and the operational claims (throughput, latency, cost) as unverified until you spike them.

When to Consider This Package

Strong fit when:

• You are a Laravel/PHP shop. The value here is compounding — admin UI, capability config, scheduling, and container wiring all assume you're already in that ecosystem. Porting the concepts to another stack forfeits most of the leverage.
• Your product involves long-lived, stateful agents with memory, not stateless request/response chat. The whole design — wakes, subjective-time pulses, prompt substrate — only pays off when an agent persists across sessions and time.
• You have scheduled or proactive behavior on the roadmap (daily digests, follow-ups, recurring check-ins, monitoring). Wake's grammar (relative, absolute, daily, interval, cron, plus subjective pulse units) covers most product phrasings without custom scheduler code.
• Data residency or on-prem is a requirement. Local voice providers and the local-by-default stance are the differentiator; if you don't need them, you're paying for a constraint you don't have.
• You need voice in live conversation and/or over non-browser channels, and you want STT and TTS independently swappable so you can mix browser recognition with a good local neural voice.
• You are prepared to operate containers (the bundled voice-service) and a queue/scheduler with at-least-once semantics. This is real ops surface, not a composer require.

Look elsewhere or scope down when:

• You want a stateless chatbot. Wake, Mode self-editing, and subjective time are dead weight; you'd be adopting operational complexity for capabilities you disable.
• You're not on PHP/Laravel. The integration cost likely exceeds the feature value unless you're deliberately standardizing on this runtime.
• You need a managed SLA with a vendor throat to choke. Self-hosted means you own the pager for the scheduler, worker crashes, and voice container health.
• You cannot tolerate prompt drift risk and aren't willing to invest in reviewing diffs. The package gives you the tools (versioning, revert, annotation); it does not make the governance decision for you. If nobody owns that review, leave self-editing off and expect to stay off.
• Your voice quality bar is high-end commercial neural TTS across many locales. Five languages ship in the catalog; verify coverage against your market before committing.
• You need hard exactly-once delivery semantics. At-least-once with recompute-after-dispatch is the documented model — correct for reliability, but it means your wake handlers must be idempotent. If your downstream actions aren't, that's your engineering work, not the package's.
• Your CPU budget is tight for voice. "Twice as fast as realtime on a mid-range CPU" is a real constraint; concurrent transcription will need sizing or a GPU path.

Adoption posture: v1.0.4 is a post-1.0 minor with new migrations, new admin surfaces, and a new container. Adopt behind flags, spike the scheduler semantics (crash-during-dispatch, recurring recompute) and the voice container in a staging environment, and pin versions until you've validated upgrade paths.

How to Pitch It (Stakeholders)

To executives — one paragraph. This package now covers three capabilities that would each have been a multi-month internal build: agents that schedule their own future actions, production-grade speech in and out with a privacy-preserving local default, and a governed mechanism for agents to improve their own instructions with full version history and revert. For a Laravel-based product the practical effect is a shorter path to differentiated, persistent agents and a credible answer to enterprise security review — without sending customer audio or prompts to a third party. It also opens voice to on-prem and regulated segments we previously couldn't serve.

To engineering — the honest engineering case. You get a durable, agent-facing scheduling layer with a sane grammar and documented at-least-once semantics; a capability abstraction that makes STT/TTS a per-preset config rather than a browser feature; and a prompt-substrate layer with snapshotting, diff, revert, and optional change annotation. What you take on: a scheduler and queue you must operate, a voice container you must size and monitor, idempotency requirements on every wake handler, and an upgrade-and-review cadence for prompt versioning. Recommended first milestone: wakes for one internal use case plus local STT/TTS in staging, with self-editing left off.

To product and design. Scheduling becomes a user-facing primitive — including user-designed wakes that the agent can distinguish from its own, which is a clean affordance for "set this up for me" flows. Voice becomes a per-agent capability with genuinely different UX tradeoffs depending on the STT/TTS pairing (hands-free live conversation favors browser STT plus local TTS; batch or non-browser channels favor local-to-local). Mode gives you an inspectable history of how an agent's behavior changed, which is a support and trust surface as much as an engineering one.

Risk register to state openly. (1) Prompt drift — mitigated by versioning and review discipline, not eliminated; someone must own diff review. (2) At-least-once delivery — duplicate dispatches are possible by design; downstream actions must be idempotent. (3) Local voice resource cost — CPU sizing and concurrency limits are real; language coverage is five today. (4) Operational ownership — self-hosting trades vendor risk for pager risk. (5) Evidence gap — these capabilities are documented in release notes but not yet validated against our workloads; the pitch should include a timeboxed spike before any roadmap commitment.