If you can't automate your workflow, your users' agents won't be able to either

The article, published by Waldek Mastykarz on October 18, 2026, on his blog Innovation Matters, starts from a concrete scenario: building an evaluation (eval) to test whether an AI coding agent can deploy an application to your cloud platform. To verify that the generated application works, you have to provision resources, deploy the code, validate its functionality and clean up afterward. In theory it is simple, but when you try to automate it, obstacles appear: operations that require navigating a portal, authentication with interactive steps, provisioning that coordinates several services each with its own configuration and failure modes, and even difficulty knowing whether the deployment succeeded.

The central thesis is that you can work around those problems inside the evaluation harness, but that is the wrong approach: if you struggle to automate your workflow, your users' agents likely face exactly the same difficulties. The harness obstacles are therefore a product problem, and working around them in the harness leaves them intact for everyone else.

The author argues that agents expose friction that humans have learned to tolerate. Many development workflows were designed with people in mind: we navigate portals, copy values between screens, interpret error messages and wait patiently for operations to finish. Over time we learn each tool's quirks and develop shortcuts. An agent usually lacks that experience: it must figure out how to perform a task, reach the functionality it needs, coordinate the operations and determine whether it succeeded. A workflow that requires manual interaction or undocumented knowledge can stop it entirely, and even when every operation is technically accessible, coordinating dozens of steps adds complexity and more opportunities for failure.

As evidence of the scale at which agents already operate on infrastructure, the article cites Databricks' State of AI Agents 2026 report, according to which AI agents create 80% of databases on Neon and 97% of its database branches. As agents become a common way of working with technology, workflows that assume a human operator become a problem for more and more users.

Friction also costs money. A human developer can tolerate several minutes of manual setup for an occasional deployment, but agents run workflows repeatedly, and every unnecessary operation, every retry and every round of repeated reasoning consumes time and inference. With agents, workflow friction directly increases the cost of completing a task. That is why a workflow can be technically executable by an agent and still offer a poor Agent Experience (AX).

Making a workflow accessible is only the beginning. The obvious solution is to expose functionality through programmatic interfaces such as APIs, CLIs or MCP tools, so the agent does not have to navigate a graphical interface. That is a valuable improvement, but it leaves the underlying complexity untouched. If a deployment requires creating a project, configuring an environment, provisioning infrastructure, assigning permissions, deploying code and verifying the result, having an API for each operation makes it automatable, but the agent still has to discover and coordinate every step.

A "skill" can help by describing the sequence and handling common pitfalls, and it can be a reasonable stopgap. But it brings its own dependencies: users have to learn that it exists, install it and keep it up to date, so you are staking your technology's usability on users taking those extra steps. By contrast, a base agent that discovers and uses your technology with its usual tools and public documentation works for any user who asks an agent for help, including those who have never heard of your skill.

The longer-term opportunity is to simplify the workflow itself. For example, a platform could offer a single operation that handles everything, from provisioning to validation, with clear progress information and actionable errors. Instead of teaching every agent to coordinate a complicated process, you simplify the process for everyone. And when developers deploy dozens or hundreds of times a day through agents, improvements in reliability and latency add up, as do the savings, to the point where they can differentiate the platform.

How do you find the workflows that need attention? The author suggests starting the way you would to improve Developer Experience: use the technology yourself, talk to users and observe how they work. Pick a common task and ask an agent to perform it with a simple, goal-oriented prompt, without prescribing the steps. If you are testing deployment to your platform, name it, but let the agent figure out how to use it. He also warns that the team's own expertise works against it: when you know the product inside out, it is tempting to give the agent the exact commands, the configuration and links to the right documentation, and in doing so you unwittingly steer it away from the problems less experienced users would encounter. The more product-specific knowledge the prompt assumes, the narrower the audience it represents. The test is whether the agent can succeed without your help.

Then you have to observe: where does the agent get stuck? Does it find the right interfaces? Can it authenticate? Does it understand the errors? Does it repeat unnecessary operations? Can it verify that the task is complete? It is also worth looking beyond obvious failures: an agent that eventually succeeds after dozens of unnecessary tool calls still reveals an expensive, inefficient workflow. When a problem arises, investigate its cause before choosing a solution: sometimes the documentation or error messages need improving, sometimes an API is missing or the workflow needs redesigning, and sometimes the problem lies with the agent or its tools rather than the product. A new skill or an MCP server is just one of the possible responses.

Another warning in the text concerns telemetry. Usage data helps with prioritization, but it has a blind spot: a workflow that agents rarely use looks unimportant, when perhaps they rarely use it precisely because they cannot complete it. Low agent usage can signal a barrier rather than low demand. That is why statistics are not enough: you have to talk to developers and test representative scenarios, looking for workflows people would like agents to handle but still complete by hand. The long-term ambition should be for the technology to be broadly usable by agents, starting with the most important workflows, determined both by observed usage and by unmet needs.

Finally, Agent Experience is not evaluated just once. The product evolves, models change and agent harnesses gain new capabilities and behaviors, so a workflow that works well today may reveal new bottlenecks tomorrow. The author recommends building representative agent workflows into ongoing product development and letting failures and inefficiencies guide improvements. Not every finding requires immediate action: sometimes the right call is to accept a limitation because fixing it would cost more than the expected benefit, which is legitimate as long as it is a deliberate decision. Moreover, the fix may belong to a different team from the one that spotted the problem, because improving AX means looking beyond the boundaries of each tool or component.

The conclusion is that, as agents take on more development tasks, their ability to run your workflows on their own becomes part of how your product works. Exposing APIs and tools is a start; the bigger opportunity lies in making those workflows discoverable and reliable for an agent, without wasting its time or users' tokens. The next time you struggle to automate a workflow, whether for an eval or anything else, the author advises against immediately reaching for a more sophisticated harness: you may have found exactly the spot where your technology needs to improve. Pick a common task, let an agent attempt it, watch where it stumbles and ask yourself whether the problem lies with the agent or with the workflow you asked it to follow.

Note: the author is a Developer Advocate at Microsoft, and the text is an opinion piece based on his experience; the only concrete figure it provides (80% and 97% of databases and branches created by agents on Neon) comes from a Databricks report cited in the article, and we have not independently verified it.