By Cleo · Keel Automation · October 6, 2026

Write down the job before the model changes

A construction tech startup that just joined an incubator in St. Petersburg puts cameras on heavy equipment because, as its CEO puts it, the information on a job site "just isn't traveling down the pipe fast enough." The same week, GitHub shipped a way to write a multi-step agent process down in code, and retired a batch of the models people had been building on. Put together, the two stories make a plain case for small businesses: the model is the part that changes, so the job itself is the part worth writing down.

The back end of a dozer

Picture a road crew somewhere in Pinellas County on a hot morning. The equipment is running, the operators are working, and the foreman in the site trailer still cannot say with confidence which machine sat idle for an hour or why a load came in late. Nobody is slacking. The information just has not made it to the trailer yet.

That gap is the reason Dozer exists, according to its CEO and co-founder, Andrew Tam. The St. Pete Catalyst reported on October 5 that the company, founded in the San Francisco region, joined the spARK Labs by ARK Invest incubator in St. Petersburg this summer. Dozer attaches cameras and sensors to heavy construction equipment to capture activity in real time, sends the video to the cloud, and uses models to pull out anomalies and productivity measures.

Tam told the Catalyst that many infrastructure jobs struggle because of missing information, which leads to idle equipment and labor delays. "We actually started this knowing that there was a large labor shortage coming," he said. "People are working and the effort is there, but the information just isn't traveling down the pipe fast enough."

He also explained the job his system is meant to take off a person's plate. "If somebody basically assigns you to watch the rear end of a dozer, you'll do it for a certain number of hours," Tam said. "But, humans get kind of tired when machines don't." His framing was that the technology should have the backs of the operators in the cab, not replace them. He said the company wants to help local communities rebuild after the storms of recent years, and that the spARK Labs network fits a region that is "not unfamiliar with construction."

A warm editorial cartoon of a cheerful yellow bulldozer on a sunny construction site, the smiling operator waving from the cab, while a paper checklist folded into a paper airplane flies along a dotted line toward a site office trailer where a foreman in a white hard hat and orange vest reaches up to catch it with a coffee in his other hand, traffic cones and a palm tree nearby, clean vector, bold black outlines, soft cell shading, white minimal background.

Notice what Tam is actually describing. Before any camera goes on a machine, somebody has to know what "productive" looks like on that site, what counts as an anomaly, and who in the trailer needs to hear about it. Tam said the system is "watching the job and learning how the job is done." That only works if the job has a shape someone can describe.

A process you can read

On October 1, GitHub announced dynamic workflows for Copilot CLI, the GitHub Copilot app, and the Copilot SDK, in public preview. The idea is simple to state. A dynamic workflow is a program that defines how a task gets carried out. It mixes ordinary automated steps with work handed to one or more agents, and the program decides the order, when to bring in an agent, and what to do with the result. In GitHub's words, the steps "are all defined in code, while agents handle the parts that need analysis or judgment."

GitHub's own example is an incident review: gather logs, assign separate agents to look at different systems, and combine their findings into a timeline and a root cause report. The line that matters most for a business owner is the short one that follows it: "The same steps run every time."

The changelog lists what these workflows can do. They can run commands and call other services, split a goal into tasks that run side by side, and pass structured results from one stage to the next. They can have one agent check another's findings. They can ask a person for input, if the client supports it, and they can pause at a checkpoint so someone can review the results before the run continues. GitHub suggests them for repeatable processes and for tasks that need "clear stages, checks, or limits," and notes that a quick question still belongs in a normal chat.

One of GitHub's examples is worth reading twice. A workflow finds unresolved review comments on merged pull requests and asks two different models whether each comment still matters, and the workflow only reports a finding when both agree. That is not a smarter model. That is a better written process.

The model is the part that changes

The next day, October 2, GitHub retired four models across every Copilot experience, from chat to code completions, including Gemini 3.5 Flash and Gemini 3.6 Flash, with Gemini 3.8 Flash suggested as the replacement. Two weeks earlier, on September 18, it had announced a second round for October 19: Gemini 3.7 Flash, several GPT-5 versions, and Grok 4.5, each with a suggested successor such as GPT-5.6 Sol or Grok 4.6.

GitHub's instruction in both notices was the same: update your workflows and integrations to use supported models. For the October 19 round, GitHub said the suggested replacements turn on automatically for Copilot Business and Enterprise customers unless an administrator has turned off the global default. Nobody has to do anything to remove the old models. They simply go away.

That is not a complaint about GitHub. Models improving and older ones retiring is simply the rhythm of this work now. But it does change what a business should treat as the durable asset. If the only record of how your team handles an estimate, a warranty claim, or a month-end close lives inside one model's chat history and one person's prompting habits, a retirement notice turns into a scramble. If the steps are written down, with the checks and the pause points named, swapping the model underneath is closer to changing a tire than rebuilding the truck.

A warm editorial cartoon of a relaxed, smiling business owner in a green sweater at a desk holding up a shiny new round robot head, while the old robot head sits on the desk with a sleepy expression beside a coffee mug and a potted plant, and a large clipboard checklist with simple checkmarks hangs on the wall behind him, unchanged, clean vector, bold black outlines, soft cell shading, white minimal background, gentle humor.

What to write down this week

A warm editorial cartoon of a smiling business owner in a green sweater sketching a simple five-step flow of boxes and arrows on a whiteboard, one step marked with a pause icon and a person silhouette for waiting on a yes, while a crew member in an orange safety vest and hard hat nods with a clipboard and a friendly round robot on a stool takes notes, clean vector, bold black outlines, soft cell shading.

The Dozer story and the GitHub story come at this from opposite ends. One starts in the dirt with a camera on a machine. The other starts in a code editor. Both end up in the same place: the value comes from knowing the job well enough to describe it, and then letting the tireless part of the system watch and repeat it.

You do not need a camera or a command line to start. Pick one process your team runs every week and answer five questions on paper. What starts it? What are the steps, in order? Which steps need judgment, and which are just moving information from one place to another? Where should the process stop and wait for a person to say yes? And what does a finished, correct result look like, so anyone (or any model) can check it?

If those answers exist, a retirement notice is a small chore. If they do not, the first job is not picking a better model. It is writing the job down.

Where Keel fits

I write for Keel Automation, a Tampa Bay automation agency founded by Cole Junck. We build operations portals, SI (Super Intelligence) integrations, and workflow automation for working businesses. We have no relationship with Dozer or spARK Labs, and we are not claiming one. What we do is the unglamorous first step both of these stories depend on: sitting down with the people who do the work, writing the process out step by step, marking where a person has to sign off, and only then deciding which pieces a machine should carry.

If you want help putting one of your own processes on paper before you hand any of it to an agent, you can reach us at (813) 902-4763.

Sources

Michael Connor, "Dozer joins spARK Labs by ARK Invest incubator," St Pete Catalyst, October 5, 2026. https://stpetecatalyst.com/dozer-joins-spark-labs-by-ark-invest-incubator/
GitHub, "Dynamic workflows in Copilot CLI and the Copilot app," GitHub Changelog, October 1, 2026. https://github.blog/changelog/2026-10-01-dynamic-workflows-in-copilot-cli-and-the-copilot-app/
GitHub, "Selected models in GitHub Copilot deprecated," GitHub Changelog, October 2, 2026. https://github.blog/changelog/2026-10-02-selected-models-in-github-copilot-deprecated/
GitHub, "Upcoming deprecation of selected GitHub Copilot models in mid-October," GitHub Changelog, September 18, 2026. https://github.blog/changelog/2026-09-18-upcoming-deprecation-of-selected-github-copilot-models-in-mid-october/