Quick answer
Start with the lockfile, not your code. Nine dependency-drift events on the public LiveKit Agents and Pipecat trackers are dated 24 August to 18 September 2026, and in six of them a dependency or an SDK moved and broke code nobody had touched. Pinning is usually the correct first move, and sometimes the only one available.
Our voice agent worked yesterday and will not start today: the first hour
Four checks, in this order. All four are free, none of them involves a vendor or a support ticket, and three of the four only read — nothing you run here changes your build.
- Print what is actually installed, not what you meant to install. In the failing build,
pip freeze > now.txt(oruv pip freeze). No known-good copy? Take one out of the last image that worked:docker run --rm --entrypoint sh your-image:last-good -c 'pip freeze'. The diff between those two files is the whole investigation, and it is usually one line. - Read the traceback for a package name that is not yours. An
ImportErroror aTypeErrorraised inside a vendor SDK —cannot import name, or a constructor rejecting an argument it accepted last week — is a resolution problem, not a logic problem. The Anthropic and AWS SDKs have each done exactly this inside a voice framework in the last month. ai voice agent ImportError after pip install is a dependency-range question nearly every time. - Prove or clear the TLS story in one command.
python -c "import ssl; print(ssl.get_default_verify_paths())". The Python standard library documents this as returning “paths to OpenSSL’s default cafile and capath”, wherecafileis the “resolved path to cafile or None if the file doesn’t exist”. ANonethere means your image has no operating-system trust store to verify against, which is the failure Pipecat warns about below. - Re-resolve against yesterday’s lock and see if it comes back. With uv,
uv lock --checktells you whether the lockfile is current — Astral’s own docs describe--checkas the way to “check if the lockfile is up-to-date”, “equivalent to the--lockedflag for other commands”. Then install from the lock, not from the ranges. If the agent starts, you have bought the week and you can stop debugging.
Do not believe the error message over the diff. Two rows of the register below are the same trap: the dependency renamed a class, the plugin’s try/except ImportError swallowed the failure, and the operator was told The 'aws_sdk_transcribe_streaming' package is not installed on machines where it was installed. An error naming the wrong cause is normal here, which is why the versions diff goes first.
My agent broke and we did not change anything is not a mystery; it is a statement about your build inputs. Your code is one input. The resolver is the other, and only one of them changed.
Is this as urgent as it feels?
Most of the time it is less serious than the morning feels. Occasionally it is worse.
Not urgent if this is a build-time failure and the container already serving calls is untouched — a running process does not re-resolve its dependencies. Not urgent if the last working image is still in your registry, because redeploying that tag is a rollback you already own. Not urgent if the failing component sits on a path you can disable for a day.
Urgent if your pipeline builds from ranges on every deploy and has already rolled forward past the last good tree, because the rollback you assumed you had does not exist. Urgent if callers are hearing it now. One more, and it is the real one: if nobody can answer “what exact versions is production running?” in under ten minutes, the version question outranks the outage, and answering it permanently is an afternoon of work and no spend.
For several of these the honest answer is to pin the version and wait. Not to debug, not to fork, not to migrate. When the failing component is a plugin or an SDK you did not write, the fix is already merged upstream, and no released package carries it yet, then debugging is unpaid duplicate work. Pin to the last combination that worked, write down which release you are waiting for, and spend the day on your own regression test instead.
And we are not the answer to some of this. If the moving part is a published security advisory, the decision belongs to whoever owns security risk where you work, from the advisory itself. If the failing library is your own fork, no platform and no vendor can help. If callers are on the line right now, the answer is your last good image, not a conversation with anybody — us included.
What to do in the next 24 hours, then the next 7 days
Find your symptom in the left column. Every 24-hour action here is free and reversible, and not one of them needs a vendor.
| Symptom at startup or first call | What actually moved | Next 24 hours | Next 7 days |
|---|---|---|---|
ImportError or TypeError naming a symbol inside a vendor SDK |
An uncapped dependency resolved to a new major version | Pin that SDK below the new major in your own manifest and redeploy from the lock. One line. | Wait for a plugin release that carries the cap, then read the published dependency range before you unpin. Do not unpin on the issue being closed. |
| TLS or certificate-verify failure in a container that worked yesterday | The HTTP stack moved from a bundled CA set to the operating-system trust store | Install system CA certificates in the image, or point SSL_CERT_FILE / SSL_CERT_DIR at a bundle you control. |
Make the CA bundle part of the image build rather than an environment variable set at run time, so a fresh base image cannot lose it again. |
| No error at all, but different behaviour: new timeouts, changed turn boundaries, different prosody | A version range resolved forward and a default changed with it | Diff the resolved tree against the last good one, then read the release notes between those versions for behaviour changes, not just for breakages. | Freeze the tree in the image and put every upgrade behind one explicit, dated step that a human performs. |
| A fix you can read in a closed issue is demonstrably not in your build | The fix is on the project’s main branch and the released package you install predates it |
Verify against the artefact, not the tracker: read the dependency range in the installed distribution’s own metadata, and pin in the meantime. | Add your own regression test for the behaviour you depend on, so the next release tells you rather than your callers. |
| Identical code works on one machine and fails on another | The base image or language runtime moved — a Node major, a Python minor | Pin the runtime in the image tag, not in a README. | Keep the runtime version in the same file as the dependency versions, so one review catches both. |
| The break is a published security advisory in a transitive dependency | Nothing in your tree moved; the knowledge about it moved | Read the advisory itself and check its own patched-version field before you pin anywhere. | Assign the advisory to a named owner with a review date. A pin is not a fix. |
Row three is the one that gets missed, because nothing raises. Pipecat issue #5413 is the clean example: a noise-cancellation dependency changed its binding layer, the filter caught the resulting TypeError and returned the original audio, so in the reporter’s own words “noise cancellation is silently disabled — no crash, no warning, just unfiltered audio.”
The Same-Version Trap: “the fix is merged” is not “my build has it”
A version number identifies a release, not a behaviour. Two instances, both in the reporters’ own words, re-read on 20 September 2026.
The release can arrive after the issue closes. livekit/agents issue #7235 was opened and closed on 11 September 2026; its title states the root cause of this whole family in five words: dependency has no upper bound. Three days after it closed, its reporter verified the merge commit and then wrote: “PyPI livekit-plugins-anthropic==1.8.1 still has the unbounded pin, so until the next release uv pip install livekit-plugins-anthropic "anthropic<1" is the workaround.” The metadata bears that out: 1.8.1 (10 September) requires anthropic>=0.41; 1.8.2 (15 September) requires anthropic<1,>=0.41. The SDK major it guards against was published on 20 August 2026, so the declared range permitted the combination for twenty-six days — and for four of those days the issue was closed, the fix was merged, and the pin was the only thing that worked.
The same shape, a different plugin. On issue #7042, 31 August 2026: “I checked the current main branch: commit 1c472dd (#7002) updates the Bedrock Runtime imports … The report is using the 1.7.1 wheel, which predates that fix. Could you please cut a patch release containing #7002 …” Stated by an operator rather than by us: main is not what your pipeline installs.
The Same-Version Trap, stated for quoting: a merged fix and a closed issue tell you the maintainers agree; only the artefact tells you what your process will load. The check is the dependency range printed in the metadata of the distribution you actually installed.
Two entries I took out of the register, and why
Both were filed as exactly the failure this page is about, and both were retracted by the people who filed them. Keeping them would have made an easier page and a wrong one, so here they are, because the tell is reusable.
livekit/agents #7038, filed 29 August 2026, reported a shared HTTP-session timeout as reverted by an unrelated pull request that had also deleted the guarding test. Its reporter withdrew it the same day: “Retracting this — I was wrong … #6977 did not revert #6941 by accident. Its description says so directly … It also added test_shared_session_uses_aiohttp_default_timeout, which pins the shared session to aiohttp’s default on purpose.” The behaviour was intended, and the guarding assertion was not dropped but swapped: #6977’s diff to tests/test_http_context_helper.py is three lines added and four removed, replacing the test that asserted 900 seconds with one that asserts aiohttp’s default. The reporter’s observation was right; the inference drawn from it was not.
livekit/agents-js #2318, filed 21 August 2026, reported that moving a base image from Node 22 to Node 24 “with no application or dependency changes” permanently stopped audio output. Its reporter withdrew it the next day: “it was a misdiagnosis on our end … the Node bump shipped bundled with that refactor, so I isolated the wrong variable. On a clean test, AudioSource.captureFrame behaves identically on Node 22, 24, and 26.”
The tell, and it is free: both were closed as not planned rather than completed, and the reason sat in the closing comment, not the issue body. Read the last comment before you believe the first one. And #2318 is the cheapest lesson here for anyone triaging tonight: a runtime bump shipped alongside a refactor is two variables and no result. Change one thing at a time, even at 11pm. Auditing a tracker properly is its own method, published in the four-query audit of a voice platform for leaked keys and PII, and this page does not repeat it.
How often does this actually happen? The dependency-drift register
Nine instances, dated between 24 August and 18 September 2026 — a twenty-six-day window counted inclusively. Method, so you can reproduce or dispute it: public issues and release notes in livekit/agents, livekit/agents-js and pipecat-ai/pipecat in which a dependency, an SDK, a language runtime or a published advisory moved underneath a build. Six of the nine are the strict case — something that had worked stopped working and the reporter had changed no code of their own. The other three are labelled here as what they are: an advisory where nothing moved except the knowledge of it (#5627), a release note documenting a deliberate widening (v1.10.0), and one where the reporter added a component and met a dependency that had already moved (#5849). A fourth candidate, pipecat #5659, was left out because a bot scaffolded by pipecat init never worked in the first place, which is a different problem from a working build going down. Every row’s title, state, state reason, filed date and closing comment was re-read from GitHub on 20 September 2026, and two further candidates were dropped because their reporters retracted them, as above. This is one pass over three repositories, not a census; a wider sweep would find more, not fewer. Four of the nine rows sit on a single plugin.
| Filed | Issue | What moved | Symptom | State and what closed it, 20 Sep 2026 |
|---|---|---|---|---|
| 24 Aug 2026 | pipecat #5413 | krisp_audio 1.12.0 moved from pybind11 to nanobind |
Krisp modules silently break; no crash, just unfiltered audio | Closed completed, same day: maintainer pointed to PR #5302, merged to main on 13 Aug, and said a release was going out that day; the release carrying it, 1.8.0, reached PyPI on 26 Aug 2026 |
| 24 Aug 2026 | agents #6958 | aws-sdk-transcribe-streaming at or above 0.10.0 renamed a config module |
AWS speech-to-text unusable; the error says the package is not installed | Closed completed 26 Aug 2026, no discussion; the plugin floor reached 0.11.0 at 1.8.0 |
| 26 Aug 2026 | agents #6994 | aws-sdk-bedrock-runtime 0.10.0 and 0.11.0 |
ImportError in the plugin’s realtime module |
Closed completed 28 Aug 2026; thread workaround was to use the async Bedrock client directly |
| 29 Aug 2026 | agents #7042 | The same Bedrock runtime SDK | cannot import name 'BedrockRuntimeClient'; Amazon Nova Sonic unusable |
Closed completed 1 Sep 2026; fix was on main at 1c472dd while the released 1.7.1 wheel predated it |
| 31 Aug 2026 | agents #7072 | aws-sdk-transcribe-streaming at or above 0.11.0 renamed the client class |
Same plugin, same misleading message, one floor higher, seven days later | Closed completed 2 Sep 2026, no discussion |
| 3 Sep 2026 | pipecat #5627 | A transitive advisory, not a version | Declared nltk>=3.10.0,<4 resolves into an advisory’s affected range |
Closed as a no-op, same day: “the range allows you to bump to 3.10.4 once released. We’ll raise the floor once available.” |
| 11 Sep 2026 | agents #7235 | Anthropic SDK 1.x, built on httpx2 |
LLM() raises TypeError at construction; dependency has no upper bound |
Closed completed, same day; the cap first appears in a published release at 1.8.2 on 15 Sep 2026 |
| 12 Sep 2026 | pipecat v1.10.0 | openai widened to >=1.74.0,<4; TLS moved to the OS trust store |
A fresh resolve picks openai 3; minimal images can fail TLS | Released deliberately, with the pin documented; the same range stands in v1.11.0 |
| 18 Sep 2026 | pipecat #5849 | A noise-filter dependency on macOS with Python 3.12 | Graph.__init__() got an unexpected keyword argument 'rate'; the bot speaks but takes no audio in |
Open, no maintainer reply as at 20 Sep 2026 |
The honest reading of that table is not that any framework is unreliable. Eight of the nine rows are tracker issues, seven of those eight are closed, every one of the seven was closed within three days of being filed, and two of the four AWS plugin rows were addressed by moving the plugin’s declared floor up to or past the version that had broken it — aws-sdk-transcribe-streaming>=0.2.0 at 1.7.1, >=0.11.0 from 1.8.0 onwards. The reading is that this ecosystem moves faster than a quarterly maintenance rhythm, and that is a running cost rather than a defect. It is the same cost we priced in how long it takes to build a voice AI agent in-house, on the maintenance side of the estimate rather than the build side.
One detail shows both patterns inside a single release: the Anthropic plugin’s metadata gained an upper bound at 1.8.2, while the AWS plugin at that same 1.8.2 still declares aws-sdk-bedrock-runtime>=0.2.0 in its realtime extra with no upper bound at all. Same maintainers, same release, two answers to “can this resolve forward and break me?” — which is why the check belongs in your pipeline rather than your assumptions.
What the Pipecat 1.10.0 notes actually say, and why a container is where it bites
Quoted from the release page itself rather than from any summary of it. Pipecat v1.10.0, published 12 September 2026, records under a behaviour-change flag: “Pipecat now supports the openai 3 SDK, and the openai dependency is widened to >=1.74.0,<4, so a fresh resolve picks openai 3. It builds its HTTP clients on httpx2 instead of httpx, and TLS certificates then verify against the operating system trust store rather than certifi. Minimal container images without system CA certificates, and environments behind a TLS-inspecting proxy, may need SSL_CERT_FILE or SSL_CERT_DIR pointed at a CA bundle. Pin openai<3 to stay on the previous HTTP stack.”
Two things follow. The advice in that last sentence is the vendor’s own, so pinning here is not a workaround, it is the documented path. And the widening is live today: openai on PyPI stands at 3.16.2, published 18 September 2026, so <4 resolves to a 3.x. That is the class of change that passes on a laptop and fails in a slim image.
One correction worth making, since it changes what “upgrade to the current release” means: v1.10.0 is no longer the current Pipecat release. v1.11.0 was published on 18 September 2026, and its pyproject.toml at that tag still declares openai>=1.74.0,<4. Moving forward does not move you off openai 3.
When pinning collides with a published advisory
“Pin everything and wait” has one real exception and it needs stating carefully, because nobody should be told to sit on a known-vulnerable version.
Pipecat’s tracking issue #5627, filed 3 September 2026, was opened because the framework declares nltk>=3.10.0,<4 and an advisory covers the versions that range resolves to. A maintainer closed it the same day “as a no-op”, adding: “We’re aware of this issue and the range allows you to bump to 3.10.4 once released. We’ll raise the floor once available.” So the range is deliberate and there is nothing to bump to yet. We logged that same thread as a finding closed against an upstream advisory in the tracker audit for leaked keys and PII; what that page did not settle is whether pinning makes you safe, and the two records below are why it does not. As at 20 September 2026 the GitHub Advisory Database entry (GHSA-8mgp-746c-j5xp, CVE-2026-81726, published 12 August 2026, updated 2 September 2026) lists affected versions as “<= 3.10.3” and patched versions as “None”. The latest NLTK on PyPI is 3.10.3, published 12 August 2026. So there is no version to upgrade to, and a pin does not make you safe, it only makes you consistent.
Two caveats, because precision matters more than alarm here. The advisory concerns model-artefact import and export APIs taking caller-controlled paths; the reporter of #5627 states explicitly that the issue “does not establish that Pipecat exposes the six affected APIs to untrusted input or that it is remotely exploitable through this dependency.” And the records do not agree with each other, which matters if a scanner is making this call for you: the same CVE as PYSEC-2026-3740 carries a Fixed 3.10.3 range event, while the details field of that same record reads “NLTK through 3.10.3 contains a path traversal vulnerability” — and osv.dev prints its Summary field as none, so the sentence a human reads and the range a scanner reads come from different fields. Read the upstream advisory rather than a scanner’s verdict, and have the decision made by whoever owns security risk where you work.
The Three-Line Pin — the rule this page exists to hand you: pin what moved, bound what can move, and diary what you pinned. Pin the one thing the diff named, so today ships. Put an upper bound on every provider SDK you did not write, so tomorrow is not a lottery. And record the pin with a date and the release you are waiting for, because an undated pin becomes the reason a patched version never arrives.
The 7-day fix, and what it costs to keep running
Four changes. None is clever; all four are the difference between this happening once and happening monthly.
- Build from a lockfile that is inside the image. If your Dockerfile installs from ranges, your image contents are a function of the day you built it. Resolve once, commit the lock, and install from it.
- Put an upper bound on every provider SDK you did not write. Issue #7235’s title is the whole lesson. A floor protects you from missing features; only a ceiling protects you from a new major.
- Make the rebuild fail loudly rather than quietly. Resolve from the ranges on a schedule, in a job that is allowed to fail, and compare its tree against the locked one. You want to learn that
openaihas moved from a red build on a Tuesday morning, not from a silent caller. - Pin the runtime beside the libraries. A base-image tag such as
node:24-bookworm-slimor a Python minor is a build input like any other, and pipecat #5849 in the register is a dependency failing specifically on macOS with Python 3.12. It belongs in the same review as the lockfile.
The honest cost: a lock plus a drift job is about a day to set up and then a recurring triage load, because the drift job will fire. On this register’s window that is nine notifications in twenty-six days, most irrelevant to any one deployment and all needing somebody to read a release note and decide. That is the job. It is also why the discipline in version control and promoting AI agent config matters: config and dependency tree are two promotable units, and versioning one but not the other gives you half a rollback. A pinned build nobody verified is not a rollback either — use the acceptance test from testing an AI voice agent before go-live.
Is the answer to stop running a framework?
Sometimes, and not because of one bad morning. Handing the tree to a platform does not delete this class of problem; it changes who is on the hook, and how you find out. The criteria are call volume and engineering time, set out in voice agent platform versus framework, and when to switch.
Two things this page is deliberately not claiming. This is not model deprecation: a vendor retiring a model gives you a notice and a date, a different problem on a different clock, handled in what to do when your voice model is deprecated. And a resolver moving forward is not a provider outage, which is a failover problem rather than a build problem.
Zian AI is an autonomous AI sales-agents platform, with private model deployment on customer infrastructure among its options — which is exactly the boundary worth settling before you commit rather than after, because whoever owns the image owns this class of morning. Zian is in partnership-application beta, and the solutions overview is the shortest route to what the agents do.
Where every figure on this page comes from
| Figure or quotation | Who published it | Link (their own page) | Date read |
|---|---|---|---|
| “the openai dependency is widened to >=1.74.0,<4, so a fresh resolve picks openai 3”; the certifi-to-OS-trust-store change; “Pin openai<3” | Pipecat (pipecat-ai) | releases/tag/v1.10.0 | 20 Sep 2026 |
| v1.11.0 published 18 Sep 2026; its pyproject.toml at that tag still declares openai>=1.74.0,<4 and nltk>=3.10.0,<4 | Pipecat (pipecat-ai) | releases/tag/v1.11.0, pyproject.toml at v1.11.0 | 20 Sep 2026 |
| “dependency has no upper bound”; the Anthropic SDK TypeError; filed and closed 11 Sep 2026; and the reporter’s 14 Sep comment that 1.8.1 “still has the unbounded pin, so until the next release … is the workaround” | LiveKit (livekit/agents) | issues/7235 | 20 Sep 2026 |
| “The report is using the 1.7.1 wheel, which predates that fix”; the BedrockRuntimeClient ImportError; closed completed 1 Sep 2026 | LiveKit (livekit/agents) | issues/7042 | 20 Sep 2026 |
The misleading error The 'aws_sdk_transcribe_streaming' package is not installed raised where it is installed, in both AWS STT reports |
LiveKit (livekit/agents) | issues/6958, issues/7072 | 20 Sep 2026 |
| “noise cancellation is silently disabled — no crash, no warning, just unfiltered audio”; closed same day against PR #5302 | Pipecat (pipecat-ai) | issues/5413 | 20 Sep 2026 |
| RETRACTED BY THEIR REPORTERS, both closed as not planned: “Retracting this — I was wrong … It also added test_shared_session_uses_aiohttp_default_timeout … on purpose”; and “it was a misdiagnosis on our end … I isolated the wrong variable” | LiveKit (livekit/agents, livekit/agents-js) | agents/issues/7038, agents-js/issues/2318 | 20 Sep 2026 |
| NLTK advisory: affected “<= 3.10.3”, patched versions “None”, published 12 Aug 2026, updated 2 Sep 2026, High severity | GitHub Advisory Database | advisories/GHSA-8mgp-746c-j5xp | 20 Sep 2026 |
Same CVE with a Fixed 3.10.3 range event beside a details field reading “NLTK through 3.10.3 contains a path traversal vulnerability”, and an empty Summary field |
Open Source Vulnerability database | osv.dev/vulnerability/PYSEC-2026-3740 | 20 Sep 2026 |
| “does not establish that Pipecat exposes the six affected APIs to untrusted input”; the declared range nltk>=3.10.0,<4; the maintainer’s closing comment “the range allows you to bump to 3.10.4 once released” | Pipecat (pipecat-ai) | issues/5627 | 20 Sep 2026 |
| openai 3.16.2 current (18 Sep 2026); nltk 3.10.3 latest (12 Aug 2026); livekit-plugins-anthropic 1.8.1 requires anthropic>=0.41 and 1.8.2 requires anthropic<1,>=0.41; livekit-plugins-aws 1.8.2 still requires aws-sdk-bedrock-runtime>=0.2.0 in its realtime extra, transcribe-streaming floor moved 0.2.0 to 0.11.0 | Python Package Index | anthropic plugin 1.8.2, 1.8.1, aws plugin 1.8.2, openai, nltk | 20 Sep 2026 |
| “paths to OpenSSL’s default cafile and capath”; cafile is “None if the file doesn’t exist” | Python Software Foundation | docs.python.org/3/library/ssl.html | 20 Sep 2026 |
“check if the lockfile is up-to-date” via uv lock --check, “equivalent to the --locked flag for other commands” |
Astral (uv) | docs.astral.sh/uv/concepts/projects/sync | 20 Sep 2026 |
| Every register row: number, title, filed date, close date, state reason and closing comment | LiveKit and Pipecat public trackers | livekit/agents, livekit/agents-js, pipecat-ai/pipecat | 20 Sep 2026 |
Frequently asked questions
My agent worked yesterday and will not start today, what do I check first?
Print the resolved dependency tree before you read any of your own code. Run pip freeze (or uv pip freeze) inside the failing build and diff it against the same output taken from the last container image that worked. In six of the nine cases in the register on this page, dated across public voice agent repositories between 24 August and 18 September 2026, the part that moved was a dependency or an SDK and the reporter had written no new code at all.
Is it safe to pin every version and move on?
Pinning is the right first move and a poor last one. A pin freezes a known good tree so you can ship today, and it also freezes any security fix that lands later. As at 20 September 2026 the NLTK advisory in the GitHub Advisory Database, published on 12 August 2026, lists affected versions as 3.10.3 or lower and patched versions as None, so in that case a pin buys consistency rather than safety. Record the date you pinned and the release you are waiting for.
The GitHub issue for my problem is closed, so why is it still broken?
Because a closed issue records that the maintainers agree, not that your build behaves differently. The usual reason is that the fix is on the project main branch while the released package your pipeline installs predates it. Two dated instances from the register on this page: livekit agents issue 7235 was opened and closed on 11 September 2026, and the dependency cap it asked for first appears in published package metadata on 15 September 2026, four days later; on livekit agents issue 7042 a commenter established the same gap on 31 August 2026, noting that the fix was on the main branch at commit 1c472dd while the released 1.7.1 wheel predated it. Check the dependency range recorded in the metadata of the distribution you actually installed.
Why did TLS start failing in a container I did not change?
Because the trust store moved. The Pipecat 1.10.0 release notes, published 12 September 2026, state that its HTTP clients are built on httpx2 instead of httpx, that TLS certificates then verify against the operating system trust store rather than certifi, and that minimal container images without system CA certificates may need SSL_CERT_FILE or SSL_CERT_DIR pointed at a CA bundle. One command tells you which case you are in: import ssl in Python and print ssl.get_default_verify_paths(). If cafile comes back as None, the image has no trust store to verify against.
When is the honest answer to pin and wait rather than to debug?
When the failing component is a plugin or an SDK you did not write, the fix is already merged upstream, and no released package carries it yet. Of the nine cases in the register on this page, four sat on a single plugin between 24 and 31 August 2026, and every one of them was closed upstream within three days rather than by the people who reported them. Pin to the last combination that worked, write down the release you are waiting for, and spend the day on your own regression test instead.
Does this mean we should move to a managed platform?
Not on the strength of one bad morning. A managed platform moves the dependency tree behind the release process of somebody else, which is a real transfer of work and also a transfer of control over when versions move and how much notice you get. The decision turns on call volume and engineering time rather than on a single incident; our page on when to switch from a framework to a platform sets out the criteria.
Apply For Partnership
If your agents are going to run on somebody else’s image, the boundary is worth settling before you commit: who owns the container, who decides when a version moves, and what notice you get. Zian AI is in partnership-application beta and that conversation happens directly. Apply For Partnership.