Before Buying More AI Seats, Fix One Handoff

Once an AI tool can do a task adequately, adoption depends on whether the surrounding workflow makes that ability usable.

Consider an illustrative CI failure. An engineer sees a red notification, opens the repository, finds the run, copies an error into a chat and answers questions about the branch. The assistant may give a good answer. The engineer has still assembled the context, connected the systems and worked out what happens next.

Give a colleague the same model and the same prompt template, and those jobs remain. I would fix that handoff before buying more seats for this task.

Keep the event attached to the question

The bot code on this site contains a small version of that change. When someone replies to a notification, stored context can accompany the message: the provider, event type, selected fields and notification time. The assistant can query recorded webhook events and extract details from the relevant payload.

For a GitHub workflow event, that includes the workflow name, branch, commit, conclusion and run URL. The useful difference is that the conversation starts with an identifiable event. The person does not have to rebuild its identity from a screenshot.

A proposed output could look like this. These values are illustrative, not a real failure report:

The unknown belongs in the output. Extracting a failure conclusion is not diagnosing its cause.

That is also where the current implementation stops. Its analysis tool extracts fields already present in the webhook payload; it does not fetch full job logs. This bot has no repository-editing or deployment tool registered. A useful triage handoff is a defensible claim. “The agent fixes CI for me” would be a different system.

I would assemble those metadata fields deterministically. Copying a commit and run URL from a payload does not need a model. A model has to earn its place in later work, such as interpreting the failure once the logs are available. Improving this handoff makes that work easier to start; it does not establish that AI adds value to the extraction step.

Define what crosses the handoff

For this workflow, I would make completion mean: identify the relevant run, provide the evidence link, distinguish recorded facts from an unexamined cause, and identify the next action. A fluent explanation without the right run attached would fail that contract.

The failure path needs a contract too. If the recorded event has expired or cannot be retrieved, the output should say so. “No recorded active failures” cannot establish that production is healthy. If the next owner lacks access to the logs, the handoff is blocked at a specific permission boundary; a confident guess does not repair it.

This is a smaller version of the tools-to-teammates transition: work arrives with the context needed to do a bounded job, and leaves in a form someone else can use.

DORA’s AI Capabilities Model makes a related point at organizational scale, identifying AI-accessible internal data, healthy data ecosystems and quality internal platforms among its capabilities. That research gives the surrounding work a name. It does not prove that this particular bot saves time.

Try it without the enthusiast in the room

There are other constraints. The model might be inadequate. Access may be restricted for good reasons. Some tasks are too variable to justify maintaining a workflow. Better integration cannot wish those problems away.

But when a capable tool is used only by the person who assembled it, try a smaller adoption test: choose one recurring handoff and let a colleague run it from the supplied input to the next decision. Record where they have to reconstruct context, ask the original author or interpret an ambiguous result.

Then change that part of the workflow and try again. Count the setup, maintenance and follow-up work before claiming a saving. The useful result is a colleague who can identify the right failed run and continue the investigation without you filling in the missing steps.