From autocomplete to agents

The first wave of AI coding tools completed lines and functions. The current wave plans and executes multi-step tasks — reading a codebase, writing code across several files, running tests, and iterating on failures with limited supervision. That’s a change in kind, not just speed: the unit of work an AI touches has grown from a line to a feature, and the human’s job has shifted from typing to reviewing and directing.

Standardized plumbing is enabling standardized agents

Protocols like MCP are doing for AI tool access what REST and later GraphQL did for web APIs: turning bespoke integration work into a shared, reusable layer. That standardization is what makes it economical to build agents that reach into real systems, rather than agents that only talk. See our companion piece on what MCP actually is.

The bottleneck has moved, not disappeared

Code generation was rarely the actual constraint on software delivery — requirements clarity, architectural judgment, and review capacity were. AI tooling makes the easy 80% of implementation faster, which means the remaining 20% — the ambiguous requirements, the cross-system trade-offs, the “is this actually the right thing to build” conversations — is now a larger share of where a team’s time goes.

What we’d actually bet on

• Brownfield-aware AI coding practices becoming table stakes, not a specialty (see our piece on brownfield vs. greenfield).
• Agentic workflows handling more internal, reversible work before they’re trusted with customer-facing actions.
• Governance — audit trails, approval gates, rollback paths — becoming a normal line item in AI project scope.
• Model and provider choice being treated as a swappable architectural decision rather than a permanent commitment.

Summary: None of this requires believing AI will write all the code or none of it. It requires paying attention to where the actual mechanism has changed, and building the engineering discipline around it before the incidents force the issue.

#AI #SoftwareDevelopment #AgenticAI #FutureOfWork #SazkoSolutions

Published by Sazko Solutions – Driving Innovation in AI-Powered Software Delivery

The post The Future of AI in Software Development: What’s Actually Changing appeared first on Sazko Solutions.

Why node-based automation and AI turned out to fit so well

An AI agent that has to write and execute arbitrary code for every task is powerful but unpredictable — it’s hard to review, hard to constrain, and hard to debug when it fails silently. A workflow made of discrete nodes — fetch this, transform that, call this model, branch on this condition — gives an agent (and the humans supervising it) a much narrower, auditable surface. n8n’s approach of letting an AI node sit alongside conventional integration nodes means a business process can mix deterministic steps with model-driven judgment calls, without the whole pipeline becoming a black box.

What this actually replaces

• Manual triage and routing (support tickets, leads, documents) that previously needed a person to read and decide.
• Brittle point-to-point integrations, replaced by a workflow that can adapt its next step based on what a model observes.
• One-off scripts that quietly became “critical infrastructure” nobody wanted to touch.

The trade-off worth naming

Low-code AI workflows are easy to start and easy to outgrow. They’re excellent for well-bounded automation and painful for anything that needs real software engineering discipline — version control, proper testing, code review. The teams getting the most value treat n8n-style orchestration as the front door for automation, and graduate a workflow into real code the moment it becomes complex enough that “flow diagram” stops being an honest description of what it does.

Summary: n8n didn’t invent AI-orchestrated automation, but its node-based model is a big part of why the idea became practical for teams without a dedicated AI engineering function.

#AI #Automation #n8n #Workflow #SazkoSolutions

Published by Sazko Solutions – Driving Innovation in Automation, Agile, and AI

The post n8n and the Rise of AI-Orchestrated Workflows appeared first on Sazko Solutions.

One-shot vs. long-running

A one-shot agent takes a request and returns a result; if it’s wrong, you try again. A long-running agent holds a goal across hours or days, accumulates state, and takes many actions before anyone checks the outcome. The failure modes are different: drift, compounding small errors, and actions taken on stale assumptions.

What “learning between sessions” needs from you

• A durable record of what the agent did and why, that both the agent and a human can review.
• Checkpoints where a person confirms direction before the agent commits to the next phase.
• Clear boundaries on what the agent can change without approval, especially as it gets more autonomous.

The trust curve

Agents that improve over time are more useful and harder to reason about — the thing making decisions this week isn’t quite the thing you evaluated last month. Treat capability growth as a reason to strengthen oversight, not relax it.

Summary: Long-running, self-improving agents are a real step forward in usefulness. The operational discipline they require is a step up too, and it doesn’t come in the box.

#AI #AgenticAI #Automation #EnterpriseAI #SazkoSolutions

Published by Sazko Solutions – Driving Innovation in Agentic AI and Automation

The post Agents That Learn Between Sessions: The Move to Long-Running AI Workflows appeared first on Sazko Solutions.

Why this is a bigger shift than better autocomplete

A traditional application does exactly what its code says, every time. An agentic system decides, at runtime, what to do next based on incomplete information and its own prior output. That’s enormously useful for tasks that don’t have a clean deterministic script — triaging a support queue, reconciling data across systems, running a multi-step research task — and it’s precisely why it’s harder to test, monitor, and trust than the software most teams are used to shipping.

Where enterprises are actually finding value first

• Bounded, reversible tasks — drafting, summarizing, classifying, and proposing changes a human still approves.
• Internal tooling before customer-facing systems, where the cost of a wrong action is a Slack message, not a lost customer.
• Narrow tool access — an agent scoped to three well-defined tools is far more predictable than one with open-ended access to everything.

The governance question nobody gets to skip

Once a system can act on its own, “did it work” stops being the only question. Teams adopting agentic AI seriously end up building the same things twice: the agent itself, and the harness around it — logging every tool call, capping what an agent can do without approval, and building a rollback path for when it gets something wrong. Organizations that skip the harness aren’t moving faster; they’re deferring the cost to the first incident.

Summary: The honest summary: agentic AI is real leverage, not hype, but the leverage comes from the combination of the model and the operational discipline around it, not the model alone.

#AI #AgenticAI #EnterpriseAI #TechStrategy #SazkoSolutions

Published by Sazko Solutions – Driving Innovation in AI, Agents, and Enterprise Software

The post Agentic AI in the Enterprise: From Chatbots to Systems That Act appeared first on Sazko Solutions.

The problem MCP is actually solving

An AI model is only as useful as the context and actions available to it. Without a shared protocol, every team wiring an agent to Jira, GitHub, a CRM, or an internal database was reinventing the same plumbing, often per model provider. MCP defines a common client-server contract: an MCP server exposes a tool, a resource, or a data source in a standard shape, and any MCP-compatible client — the agent, the IDE, the chat interface — can discover and use it without custom glue code.

Why this matters more than it sounds like it should

Protocols that win are rarely the most powerful option on paper — they win by being boring and universal enough that everyone builds on top of them instead of around them. That’s what happened with HTTP, and it’s the bet being made on MCP for agentic AI: once a tool is exposed as an MCP server, it becomes usable by any compliant agent, not just the one it was originally built for. For an engineering organization, that turns “which AI tool did we build this integration for” into a question that stops mattering.

Where the real work still lives

Adopting MCP doesn’t remove the hard parts of building agents — it relocates them. The protocol tells you how a tool is exposed; it says nothing about whether an agent should be allowed to use it unsupervised, what happens when a tool call fails halfway through a multi-step task, or how you audit what an autonomous agent actually did in production. Teams that treat MCP adoption as “integration solved” tend to skip exactly the governance and observability work that agentic systems need most.

Summary: We see MCP the same way we saw containers a decade ago: not the interesting part of the system, but the part that, once standardized, lets you spend your engineering effort on the parts that actually are.

#AI #MCP #AgenticAI #TechInnovation #SazkoSolutions

Published by Sazko Solutions – Driving Innovation in AI, Agents, and Enterprise Software

The post What MCP Actually Is, and Why It’s Becoming AI’s Common Plumbing appeared first on Sazko Solutions.