She Is on Vacation. Why Did Your Scheduled Agent Assign Her This Week's Work?

A teammate leaves for two weeks. The out-of-office reply is on, the calendar block is set, and the team knows she is gone. Then the scheduled agent runs on Monday morning and assigns her three new tickets, a follow-up call, and a report due on Friday. Nothing in the run failed. Every step completed. The work simply went to the one person who cannot do it.

That is the signature of an agent with no availability memory. It followed the assignment rule it was given, using the roster it had when the workflow was built. The vacation never entered that rule, because nobody stored it where the run looks.

The roster the agent reads is frozen in time

Most scheduled agents assign work from a list: a round-robin order, owners by territory, or a mapping from task type to person. That list is written once and treated as permanent. It has no dates on it, and it does not know that a person is away this week or back next week.

Availability, meanwhile, lives somewhere else entirely. It sits in a calendar, in a chat status, in a time-off tracker, or in a message to the team. The agent never reads those places, so as far as the run is concerned, everyone on the roster is available forever. The result is predictable: the agent keeps assigning work to an empty chair, and the pile grows silently until the person returns to a backlog that was never hers to carry alone.

The damage is not just the backlog. Customers wait for replies from someone who is not there, and a colleague who could have handled the ticket never sees it. By the time anyone notices, the delay has already become the customer's experience of the company. When the person returns, the first days back are spent triaging assignments that should never have landed.

Why a calendar block alone does not fix it

It is tempting to think the calendar solves this, since the vacation is already recorded there. The problem is that a calendar block is a fact about a person, not an instruction to an agent. A scheduled run does not browse calendars looking for reasons to skip someone. Unless the assignment step includes an availability check, the calendar might as well not exist.

The same gap appears with chat statuses and time-off tools. Each system knows something, but none of them is the place the agent consults before assigning. Fixing this means giving the agent one availability record it actually reads, and making the availability check a mandatory step in the run.

What an availability record needs to hold

An availability memory is small, but it has to be complete enough to drive a decision. For each person, the run needs the away window with real start and end dates, a cover (the person or queue that receives the work instead), scope (whether the cover handles everything, or only urgent items while routine work waits), and a return rule (what happens to held work when the person comes back).

With those four pieces, the assignment step changes shape. Before assigning, the run recalls the availability record for the intended owner. If the person is away, the run follows the cover rule instead of the default roster. If no cover is named, the run holds the work in a visible queue rather than assigning it to an absent owner and pretending the job is done. Holding visibly is far better than assigning invisibly: a held queue can be watched, while an assignment to someone on vacation looks finished until it is far too late.

Two details make this work in practice. First, key the record by person, not by workflow, so the support agent, the sales agent, and the reporting agent all read the same availability. Second, treat the return date as a real deadline for the record itself. When the person returns, the record should expire on its own, so the agent resumes normal assignment without anyone remembering to flip a switch back.

Partial availability and team-wide absences

Not every absence is a clean two-week block. Someone may work mornings only, take every Friday off, or be available for emergencies but not routine work. The availability record should carry that nuance as a simple rule the agent can apply: available hours, an emergency-only flag, or a reduced capacity. A record that only understands "in" and "out" will either overload a half-available person or sideline someone who could have helped.

Team-wide absences need the same treatment at a different level. Around holidays, half a team can be away at once, and a round-robin that ignores that fact will concentrate work on the few people still present. An availability-aware run spreads the load across who is actually present, and holds what cannot be staffed instead of quietly overloading the survivors.

The return-day problem

The most overlooked part of availability memory is the return. When the absent person comes back, a naive agent dumps the entire held backlog on her at once. A better return rule replays held work gradually, keeps work the cover already finished with the cover, and flags anything that went stale during the absence for re-triage.

This is also where stale records cause trouble. If an old vacation record never expires, the agent keeps routing around a person who is back and available, and the cover stays overloaded for no reason. Every availability record should carry an end date, and the run should treat an expired record as gone.

Give the run a memory it actually reads

The fix, in short, is to move availability out of scattered tools and into shared memory the agent consults before every assignment. Recall first, assign second, and write back what changed: a new absence, a cover change, a return. Every run then starts from current staffing reality instead of the roster as it looked when the workflow was first built. That is the kind of shared state Vilix AI is built to hold. It is cloud-hosted, so there is no infrastructure to manage, and the same memory is available to every agent over MCP, whether the agent runs in n8n, another automation tool, or a coding assistant. Instead of each workflow keeping its own copy of who is away, every agent reads the same record: the away window, the cover, the scope, and the return rule. The agent also keeps full conversation history, not just isolated facts, so the context behind a cover decision, like a customer asking for a specific handler, stays attached to the record instead of living in one chat thread. There is a free plan forever, a 7-day Pro trial with no credit card, and data can be exported or deleted anytime.

The next time a teammate goes on vacation, the test is simple. Run the scheduled agent and check where the work went. If assignments flow to the cover, held work sits in a visible queue, and the returning teammate comes back to a sane workload, the agent finally knows what the whole team already knew.