Next Shift

Next Shift turns messy shift handovers into tracked, verified operational work. Specialist AI agents with humans in the loop route tasks through to verified closure so nothing gets lost between shifts

Comment

I have worked in a few workplaces where shift handovers are done, and they usually had a lot of issues due to miscommunication or things falling over somewhere on the journey from A to B.

Across 24-hour operations, people finish their shifts with heaps of small but important things carried over from one shift to the other. This could be something we intended to tell the next shift but forgot, or something that wasn't communicated well. Maybe something that was supposed to arrive didn't, a request for a porter is still waiting on someone to respond, or a maintenance problem like a leaky sink in a patient's room was handed over to maintenance.

The next shift often gets these problems communicated to them as Post-it notes, messages in a notebook, something scrawled on a whiteboard, etc. I have had situations where I said to a colleague, “Hey mate, that back door is still not closing properly. I called the guy again, but haven't heard back yet.” That was the inspiration behind Next Shift.

I chose a non-clinical hospital operations environment for the demonstration because it makes the challenge pretty clear: different departments operating 24 hours a day, with different shifts and different people, often including people from outside the business, relying on things to be carried over from one shift to the next.

I didn't want Next Shift to be something purely used in a hospital. It just seemed like a great place where a lot of non-clinical things could go wrong, and judging by some of my favourite TV shows, often do. I know there are amazing systems in place at large organisations that manage hospital shift changes, but most seemed focused on medical issues, prescriptions, or delegated clinical work. I wanted the same system to work in any 24/7 enterprise where operational work gets fumbled during the switch between one shift's people and the next. I have seen similar issues in hotels, for example, and wanted the system to handle that too.

What it does

Next Shift turns an imperfect handover into something that can dramatically improve the outcome of shift handovers. You could do a written handover, sit down and take notes, but I love the idea of not having to go back to my desk or log into another system just to make sure colleagues on the next shift know what happened on this one.

I really liked the spoken-word transcription Gemini makes so easy. In Next Shift I have one screen with one input text field that I can simply “speak to” and know the agents will take care of it after I press send. No looking for numbers, no asking for people's chat IDs, no calling around. I see something that needs doing and put it into one simple system.

After I click submit, the message is out of my hair and the first agent, the “intake agent,” makes sure my plain-English note is delegated to the right place. Its job is to interpret the handover, understand what operational issues need to be handled and by whom, and track progress from message sent to job done with evidence.

For my fictional hospital shift-handover demonstration I created agents for six specialist areas that are vital to operations but aren't medical, and hopefully translate well to other businesses too:

  1. Facilities - This agent coordinates maintenance, repairs, building issues, and workplace infrastructure. In the hospital demo this includes things like a leaking sink or an aircon dripping in the hall. In other industries it could be squeaky door hinges, light bulbs out, or other maintenance that gets ignored on a busy shift because calling department X, not getting through and leaving a message over a lightbulb is just not something I have time for right now.

  2. Asset Logistics - This agent is responsible for finding things I need and coordinating shared equipment so staff do not waste time looking for it. This could be machinery, safety equipment, or hunting down the trolley that someone didn't get around to bringing back.

  3. Language Access - The language agent handles communication support, like when an interpreter is needed for a patient. If they prefer to speak Arabic, the system can make sure the next shift has an interpreter booked rather than it becoming a last-minute rush job. In other companies it could be translators, sign language support, or other client language requirements.

  4. Discharge DME - This agent helps determine whether a person, job, or process can move to its next stage. In the hospital demo this could be home medical equipment, for example when a patient needs crutches to take home or a blood oxygen meter. The same agent could be used for supplier deliveries, installation requirements, equipment availability, or whatever else blocks finishing a job.

  5. EVS Throughput - Coordinates cleaning, reset, readiness, and turnaround of shared spaces or operational capacity. In a hospital this means preparing rooms, but it could also work in hotels, factories, airports, warehouses, or offices to make sure rooms are reset, things that should be at workstations haven't gone walkies, and the next shift isn't immediately hunting for equipment.

  6. Patient Transport - This agent coordinates the movement of people or items between locations and verifies that the transfer actually happened. For example, when a patient needs to be moved from the taxi bay to the ward by a porter. The same idea works for passenger movement, deliveries, pickups, or bringing things from point A to point B.

The AI Coverage Critic

When you record your handover task, the Gemini Coverage Critic examines the proposed issue for omissions, duplicates, conflated tasks, or incorrect routing before accepted work is persisted in the system. Often you get sent somewhere to do something and the last shift already did it.

Each accepted issue becomes durable state in Firestore. Pub/Sub wakes the correct least-privilege specialist agent, and that specialist performs only the actions it is authorised to perform, coordinates asynchronous work, and then waits for real-world evidence.

Most importantly, Next Shift does not trust claims of completion. No more “Yeah, I did that already.” In the demo I have the running-tap picture and then the fixed-tap image, but really it could be any situation. Photo evidence isn't always possible either, which is why we still have a human in the loop when those decisions need to be made.

If a frontline worker, the person actually doing the job, clicks “Completed,” the issue becomes:

CLAIMED · UNVERIFIED

It does not become closed. The guy said he did it, but did he really?

Next Shift waits for trusted evidence from the relevant system, validates that evidence, and only then allows an independent verifier to close the task.

That separation is one of the defining ideas behind the project:

No agent claim is trusted merely because Gemini said it. Operational truth must be persisted, permissioned, and verifiable.

How I built it

I built Next Shift as a governed autonomous fleet of agents, purely on Google Cloud rather than as a collection of chatbots. Vertex AI Agent Runtime and Google ADK provide the managed reasoning layer for handover intake, with managed Agent Identity.

Gemini is used where reasoning adds value. I found there were plenty of areas where it was useful, but also areas where it wasn't. The main input box was a great place for reasoning because I found myself giving vague inputs that were so sloppy only AI reasoning could really help.

The optional audio transcription quickly became the main way I interacted with the system because I suck at typing and often can't be bothered to pause and write something during a hectic shift. Gemini is also useful for independent coverage critique and for generating evidence-grounded operational improvement recommendations from historical information.

Firestore is the authoritative source of operational truth, and even if it wasn't a Google product it would still be my go-to because it just works, and the free tier really lets me develop things while staying in the same ecosystem. Models and memory are never allowed to silently override workflow state.

Pub/Sub provides asynchronous event-driven coordination. Owner-filtered subscriptions wake dedicated specialist services, with bounded retries, idempotent processing, and dead-letter handling.

The specialist fleet runs on Cloud Run, with distinct identities and constrained authority.

Rather than allowing every component to mutate workflow state, I created a dedicated State Authority service as the mutation choke point. Specialists, the Evidence Inspector, verifier, critic, Recovery Planner, and other supporting agents do not write Firestore directly.

I also built the Human Reach part using Google Chat. This lets Next Shift coordinate work with people asynchronously while retaining an important distinction: a human response can be a claim, but it is not automatically proof. Like I said before, just because someone said they did it, that might not always be the case.

I wanted Google Chat because I use Google Workspace and didn't want yet another layer of complexity. I can't tell you how daunting it is to do work when that work is on ten different platforms. Some people use WhatsApp, LINE, Signal, Telegram, Microsoft Teams, etc. All that's great, but I wanted my system integrated with where I already do my work.

Yeah, it would be cool to build it with LINE too, but then that adds more complexity. A main idea was to bring the workflow and related messaging to one central place where I don't have to stop what I'm doing, check messages, authenticate ten times, or hunt around to find out if something has actually been done. Next Shift is all Google for heaps of reasons.

The security path uses Agent Gateway and Model Armor, including fail-closed content authorisation. In my video I demonstrate a normal request being allowed while a controlled instruction-bypass attempt is denied.

The operator interface is protected with IAP, while IAM and service identities enforce boundaries between the components.

For longer-term intelligence, Memory Bank stores advisory historical context. It can identify recurring operational patterns and support plain-English recommendations, but it has no authority to change current workflow state. I want to build this out later for more reporting and business intelligence, but I'm conscious of scope creep.

I also built a controlled Recovery Planner for delayed or rejected work. It can reason about possible next actions, but it cannot execute them, alter state, record evidence, or close an issue. Operations must explicitly sanction the proposed recovery against fresh authoritative state.

The canonical successful lifecycle is:

RECEIVED → TRIAGED → ASSIGNED → ACTION_PENDING → VERIFYING → CLOSED

BLOCKED, HUMAN_REVIEW, and FAILED remain visible governed outcomes rather than failures being hidden behind an AI-generated response. I really wanted human review wherever I could to make sure not everything is on autopilot.

Challenges faced

The hardest part was realising that making the agents more autonomous can't be the goal. I've seen AI claim all sorts of things that were not true, so while it's nice to have autonomy and show off agent capabilities, having a human in the loop or extra evidence that needs confirming is really important.

Asynchronous work created its own engineering problems. Events can be delivered more than once. Workers can fail. Responses can arrive after the authoritative issue has already changed. Poison events cannot simply disappear, so the system uses resumable workflows, stale-action rejection, bounded retries, dead-letter handling, persistent history, and re-reading current state before important actions.

Security is also all Google Cloud: Agent Gateway, Model Armor, IAM, IAP, Cloud Run services, and the underlying workflow permissions.

The biggest thing for me, though, was not turning the project into a hospital-specific application and resisting the urge to keep building features. I wanted to add Google Maps, add BigQuery, add an IT agent, and I really wanted to do all of it, but I knew that would mean I wouldn't ship on time, so I left it.

Next Shift is meant to be a tool that works really well for continuous operations. It keeps unfinished work front and centre, it is accountable, secure, and verifiable when the people dealing with the issues have gone home after their shift. People often get a call in the middle of the night asking where something is or whether something has been done. Next Shift gives the next shift more clarity about what's happening and, maybe more importantly, what didn't.

What I learned

The biggest lesson was that reliable enterprise agents need constraints as much as they need intelligence. Too often I have given AI agents free rein only to be burned by it.

LLMs are excellent at interpreting ambiguous human language, especially the things I say when I'm in a hurry, extracting intent, recognising uncertainty, and reasoning about what should happen next. They are much less appropriate as the sole authority for deciding what actually happened in the physical world. They are great tools, but we still need that human in the loop to keep them honest.

I also learned that memory and operational state are different things. Having memory in the system is great, but having that memory inform decisions and identify areas of improvement based on historical trends is when it actually does something.

I didn't even have memory doing much initially. It was basically a box I wanted to tick for the competition. But it's such a shame really, isn't it? In 2026 there is so much we can actually do with data rather than just storing it in a database and never using it again, like that Excel spreadsheet that was used daily for a quarter and then forgotten about until a year later when something in there could have made a real difference.

I think I've taken the first steps to make that happen in Next Shift. Historical memory can tell a manager that the same kind of transport request repeatedly takes too long, or that a particular operational dependency frequently creates delays.

If that wheelchair not being there when it's needed has caused experienced nurses to leave the ward and go hunting for one, and over six months that has cost 20 hours of their time, then just get them another chair.

The system isn't about telling people there are issues. They know that already. Agents can understand the problem, route it to the right person who can take action, give the next shift transparency, allow people to coordinate, ensure there is evidence at their fingertips, and turn a segmented and often unclear workflow into a one-screen, one-chat system that makes sure that even though the shift ends, the work doesn't.

What's next

The synthetic hospital environment is a great start, but I want to look at other continuous operations in manufacturing, logistics, aviation, utilities, hospitality, security operations, and other places where unfinished work crossing teams and shifts leads to issues.

I think there are lots of solutions for shift management, but I also think products often evolve into becoming more complex and less integrated with people's work and how and where they actually do that work. I saw it happening with my own ideas, where I kept thinking of features that would turn Next Shift into something overlapping with other products.

I want to focus on SMBs and smaller companies that need their shift handovers to “just work” without adding another SaaS product or another layer for non-technical staff.

I also want to build on the memory to allow better decisions by managers. The system can identify recurring delays, cross-departmental dependencies, SLA patterns, and preventable bottlenecks, and turn them into understandable recommendations that the people running the operation can actually take action on.

Built With

  • agent-gateway
  • agent-identity
  • agent-registry
  • cloud-iam
  • cloud-run
  • event-driven-architecture
  • fastapi
  • firestore
  • gemini
  • generative-ai
  • google-adk
  • google-chat
  • google-cloud
  • html/css
  • identity-aware-proxy
  • javascript
  • memory-bank
  • model-armor
  • multi-agent-systems
  • pub/sub
  • python
  • rest-apis
  • vertex-ai
  • vertex-ai-agent-runtime
Share this project:

Updates

Submission history