Weekly-Scope Null-Element Tool-Crash Automation: A Post Written With Zero Client Data, Silently

An AI content-writing flow that depends on a lookup tool succeeding doesn't necessarily fail visibly when that tool crashes — if the surrounding code catches the error and lets the writing step continue anyway, the end result is still a post, still readable, still delivered. Nothing about the OUTPUT reveals that an entire category of input (in this case, everything about which client this post is actually for) never made it into the process at all. The failure is real, and it's completely invisible from the finished product alone.

The investigation traced the crash to a specific field, on a specific set of real client records: each affected client's weekly-scope array began with seven `null` entries before any real day data. The shape makes sense as a leftover from an old screen that once reserved one array slot per day of the week and, when a client moved to a different scoping mode, emptied several of those positions rather than removing them — and whatever wrote that array out to storage recorded each now-empty slot as `null` instead of leaving it out of the array entirely.

The chat tool responsible for fetching a client's creative profile — read whenever the AI content agent needs to know a client's brand scope before writing something — read a specific field off the FIRST element of that weekly-scope array, used as a shortcut to check whether a week-specific override existed. For any client whose array happened to start with one of those `null` holes, this line threw immediately: reading a property off `null` is a hard, synchronous error in the underlying language, not a soft failure. The entire tool call failed as a result — not just the one field being read, but everything else that same tool call would have returned: the client's brand restrictions, its approved fonts, its brand colors, its entire creative scope. Whatever caught that failure further up the chain let the AI agent proceed to write the requested post anyway, just without any of that context, producing a normal-looking piece of content with none of the client-specific grounding that was supposed to shape it.

The fix has two parts, deliberately kept separate. On the code side, the filtering logic that strips anything-that-isn't-a-valid-day-object from a weekly-scope array already existed, but only inside one function, unexported, unavailable to the tool that actually needed it. It's now a single, exported, documented function, and the chat tool's own client-lookup code calls it before reading anything off the array, rather than casting the raw stored value directly and trusting its shape. On the data side, a migration cleans up the seven affected clients' own stored records — deliberately conservative, removing only entries that are not objects at all (the literal `null` holes) while leaving any incomplete-but-real day object exactly where it is, since deciding a genuinely present but partial day doesn't exist would be a judgment call this migration isn't in a position to make. Confirmed after applying it: zero clients left with non-object junk in this field, and the real day counts for affected clients preserved — one client's record held twenty genuine days once the seven holes were removed, down from twenty-seven raw entries.

An account manager asks the AI content agent to draft this week's post for one of the seven affected clients. Before the fix, the tool meant to fetch that client's brand scope, restrictions, fonts and colors crashes silently on the very first element of a stored array, and the agent goes ahead and writes a generic post with none of the client's own specifics. After the fix, the same request correctly retrieves the client's real creative profile and the post reflects it.

Centriu Atlas's AI content agent can no longer be silently starved of an entire client's brand scope, restrictions, fonts and colors by a stale null hole in stored data — closing a gap where a tool crash upstream produced a normal-looking but ungrounded post downstream, with nothing in the output itself revealing that anything had gone wrong.

This fix addresses reading a client's stored weekly-scope data safely — it does not change how a client's scope is set or edited today, since the current write path was already confirmed correct and unaffected by this specific defect.

Catching a tool's crash and letting the surrounding process continue anyway keeps a pipeline from visibly breaking, but it also hides exactly the information someone would need to notice that something upstream failed — the output still arrives, just quietly worse. Centriu's fix addresses the actual read defect at its source, and shares that fix as one single function every future reader of the same field is routed through, rather than patching the one call site that happened to be found first.