DEV Community: Sam Amderson

What Is Agentic Software? How AI Agents Plan and Execute Workflows

Sam Amderson — Mon, 02 Nov 2026 09:05:55 +0000

Agentic software is software that pursues a goal on its own. Instead of following fixed screens and scripted rules, it uses AI agents that plan the steps, call tools and enterprise systems, remember context, and adjust when something fails.

That is the short answer to what is agentic software, and it changes how engineering teams build and run workflows.

The planning loop, tool access, multi-agent orchestration, and guardrails decide whether agentic software development works in production or stalls after the pilot.

Enterprise Teams Asking What Is Agentic Software Need a Different Execution Model Than Fixed Application Logic

Traditional applications run on logic someone wrote in advance. A user clicks, the code follows a set path, and the result appears. When a case falls outside that path, the application fails or waits for a person.

Agentic software works differently. You give it a goal, and it works out the route. That is why enterprise teams asking what is agentic software are really asking who decides the next step, the developer at design time or the system at run time.

Question	Fixed application	Agentic software
Who sets the steps?	Developer, in advance	Agent, at run time
What happens on an edge case?	Error or manual hand-off	Re-plan and try another route
How does it reach other systems?	Hard-coded integrations	Tools chosen per task

OpenAI's 2025 guide for builders describes agents as systems that finish tasks on a user's behalf with a lot of independence. That independence turns software from a tool into a worker, and it is the core idea behind the new software factory model of delivery.

The Planning Loop Inside Agentic Software Architecture: Goals, Task Decomposition, and Re-Planning

Every agent runs a loop. It reads the goal, picks a step, acts, checks the result, and decides what comes next. This loop is the heart of agentic software architecture, and it is what separates AI agents planning and execution from a single prompt and reply.

A model answers once. An agent keeps working until the goal is met, a limit is hit, or a person steps in. The quality of that loop decides whether the system finishes real work or wanders off task.

Goal Intake and Task Decomposition in Agentic Software Architecture

The agent first turns a broad goal into small, checkable tasks. A request like onboarding a new supplier becomes four tasks:

Collect documents
Verify details
Create records
Notify the owner

Each task has a clear finish line. In software builds, the strongest pattern is a plan that people can read and approve before any code is written, so agents start only after sign-off. Clear tasks keep the agent focused and make its work easy to review.

Re-Planning After a Failed Step in Autonomous Task Execution

Plans break. An interface changes, a record is missing, or a check fails. Fixed logic stops here. An agent handles autonomous task execution by reading the failure, adjusting the plan, and trying another route.

Good designs cap the number of retries and log every change, so a stuck agent hands off to a person instead of looping forever. Teams should test these failure paths first, because they show how the system behaves on its worst day, not its best one.

Tool Calling and Memory as the Bridge Between AI Agents Planning and Execution and Enterprise Systems

A plan means little if the agent cannot act. Tool calling and memory close that gap. Tools let the agent call a service, query a database, or file a ticket. Memory lets it carry facts from one step to the next, so it does not repeat work or lose context.

Together they form the agentic AI execution layer that connects a decision to a real system change. Without them, an agent can only describe work. With them, it can finish it.

Scope each tool. Give every tool the least access it needs.
Log every call. Record inputs, outputs, and who approved them.
Separate memory types. Keep short-term task state apart from long-term records.

Teams that skip these controls tend to find the problem during an audit, not during a demo.

Multi-Agent Orchestration in Agentic Workflow Automation: Splitting Work Across Specialized Agents

One agent can handle a narrow job. Complex work needs more. Multi-agent orchestration splits a workflow across specialized agents, each with a clear role, and a coordinator keeps them aligned.

OpenAI's guide describes two common patterns: a manager that delegates to specialists, and peers that hand control to each other. McKinsey describes an agentic AI mesh as the connecting layer that lets many agents run safely at scale.

For agentic workflow automation, this structure matters more than any single model.

Role Separation Across Enterprise AI Agents

Role separation keeps each agent simple. One agent reads incoming requests. Another pulls records from enterprise systems. A third checks the result against the rules. Because each role is narrow, its prompts, tools, and tests stay small and easy to fix.

Enterprise AI agents built this way also fail in smaller pieces, which makes a bad output easier to trace to its source. Broad, do-everything agents tend to hide their mistakes inside long, tangled reasoning.

Hand-Off Rules and Shared Context in Multi-Agent Orchestration

Most multi-agent failures happen at the hand-off. Agent A finishes, but Agent B lacks a key fact. Fix this with a written contract for every hand-off.

Hand-off element	What to define
Input	Fields the next agent needs
Output	Format and allowed values
Context	What memory is passed along
Failure	Who gets the task if it stalls

Shared context should travel with the task, not live in one agent's head. That way any agent can pick up the work.

Parallel Tracks and Dependency Control in Agentic Workflow Automation

Specialized agents can work at the same time when their tasks do not depend on each other. A backend agent and a frontend agent, for example, can build against one shared plan.

Dependencies still need a gatekeeper. Mark which tasks must finish first, and let the coordinator hold others until then.

Parallel tracks cut waiting time, but only when ownership is clear. Two agents editing the same file or record will undo each other's work.

Failure Modes and Guardrails for Enterprise AI Agents Running Production Workflows

Agents fail in ways that classic software does not. They can pick the wrong tool, act on stale data, or repeat a step many times. A wrong answer in a chat window is an annoyance. A wrong action in a payment or records system is an incident.

OpenAI's guide advises human review for high-risk actions and for cases where an agent keeps failing. Treat that advice as a design rule, not a patch added after launch. Guardrails work best in layers.

Approval gates for actions that move money, change records, or contact customers.
Spending and retry limits so one stuck run cannot drain the budget.
Step-level logs that show every tool call and decision.
Fallback owners who receive any task the agent cannot finish.

Readiness Signals Before Adopting Agentic Software Development Across Engineering Teams

Not every team is ready to run agentic software development on real systems. The strongest candidates share a few traits, and most are about process, not models.

Teams with clear requirements, test coverage, and named owners get value fastest. Teams with unclear rules and tangled systems should fix those first.

Use the checklist below as a quick gate before a pilot moves toward production. A short gate review costs little and exposes weak spots early. Each item should have a named owner and a yes or no answer.

Requirements are written down and testable.
Automated tests exist for the code agents will touch.
Every tool and system has a named owner.
Approval rules for risky actions are defined.
Logs can show each agent step to a reviewer.

Xccelera AI and the Move From Experiments to Agentic Software Development at Enterprise Scale

Most teams can build an agent demo. Fewer can run agentic software across a full delivery cycle with the controls an enterprise needs. That gap is where a platform approach helps.

Xccelera AI works on it with a multi-agent platform in which specialized agents handle backend, frontend, integration, validation, unit testing, and deployment in parallel, while people keep approval rights at the points that matter.

Each agent and its output stays visible from start to finish, so leaders can see what was built, why, and who signed off.

For decision makers, the practical test is simple. Can the system explain every step it took?

If the answer is yes, scaling from one team to many becomes a management decision instead of a leap of faith.

7 Questions to Ask Before Starting an Enterprise AI Project

Sam Amderson — Fri, 30 Oct 2026 11:31:10 +0000

Most enterprise AI projects don't fail because the model was bad. They stall because nobody agreed on what "done" means, the data lives in a system no one can reach, or the security review shows up in week ten.

Questions are cheap in week zero and expensive in week twelve. Here are seven I'd want answered before anyone opens an IDE, with what a good answer looks like and what should make you pause.

1. What problem are we solving, and how will we know it worked?

"We need an AI strategy" is not a problem. "Tier-1 support agents spend too long routing tickets" is.

A good answer names one workflow, one team that feels the pain, and a number you can measure today. If you can't state the baseline (time per task, error rate, cost per case), you can't prove the project helped, and the first budget review will be painful.

Good answer: a single use case, a baseline metric, and a target someone has agreed to be held to.

Red flag: the success criteria are "improve efficiency" or "get ahead of competitors."

2. Is our data actually ready?

Teams routinely discover this one halfway through the build. Before committing, check:

Access: can the system read the data through an API, or is it locked in exports and spreadsheets?
Quality: is it complete and consistent enough to trust, or does it need weeks of cleanup?
Freshness: how stale is it by the time the AI sees it?
Permissions: does the AI inherit the same access rules a human user would have?
Ownership: is there a named person who can fix the source when it's wrong?

An AI agent that confidently answers from outdated or over-shared data is worse than no agent at all.

Good answer: the sources are named, reachable, and owned.

Red flag: "the data is in a few places, we'll figure it out."

3. How will this connect to the systems we already run?

Enterprise AI rarely lives alone. It has to read from the CRM, write to the ticketing system, and authenticate through your existing identity provider.

Ask early:

Which systems does it need to read from, and which will it write to?
Do those systems have stable, documented APIs, or are we wrapping something legacy?
How will the AI authenticate, and with what level of privilege?
Is there a gateway or integration layer, or will every agent build its own point-to-point connections?

Point-to-point integrations feel fast in a pilot and become unmaintainable at the third agent. A shared integration layer costs more up front and pays for itself quickly.

Good answer: a list of systems, how each is accessed, and a least-privilege auth plan.

Red flag: the integration plan is "use the admin credentials for now."

4. Who owns it, and who is accountable when it's wrong?

AI systems will make mistakes. The question is whether anyone is responsible for catching them.

Decide in advance:

Who is the product owner, and who is on call when it misbehaves?
Which decisions can the system make alone, and which need a human to approve?
What does escalation look like when the confidence is low?
How do users report a bad answer, and where does that feedback go?

Human-in-the-loop isn't a sign of a weak system. It's usually what lets you ship the first version at all.

Good answer: a named owner, a clear autonomy boundary, and an escalation path.

Red flag: "the model will handle it."

5. What are our security, compliance, and governance requirements?

Bring security and compliance in during discovery, not at the launch gate. The questions are different from traditional software:

What data will reach the model, and does any of it include PII or regulated information?
Where is that data processed and stored, and does residency matter for us?
Which models and providers are approved?
What gets logged, and can we audit why the system made a given decision?
How do we handle prompt injection and untrusted input when the agent can take actions?

If your organization already has an AI policy, read it first. If it doesn't, expect these questions to become the policy.

Good answer: requirements are written down, and security has seen the architecture.

Red flag: compliance hasn't heard about the project yet.

6. What will it cost to run, and to keep running?

The prototype's bill is not the production bill. Budget for the whole lifecycle:

Inference cost per request, at the volume you expect after launch
Evaluation, monitoring, and logging infrastructure
Ongoing prompt, model, and data maintenance as things drift
The engineering time to support it, which is usually the biggest line

Work out the unit economics. If one automated task costs more than the manual one it replaces, you need to know that before scaling, not after.

Good answer: a cost per request, a monthly ceiling, and a comparison with the current process.

Red flag: the only number anyone has is the pilot's API bill.

7. How do we get from pilot to production, and what's our exit plan?

Plenty of pilots impress in a demo and die in review because no one planned the path forward. Agree on these up front:

Evaluation: a labeled test set and a pass bar, so "it seems good" becomes a measurement
Observability: traces, quality metrics, and alerts once real users are involved
Rollback: a feature flag or kill switch that works in minutes, not days
Portability: how hard it would be to swap the model or vendor later
Stop criteria: the result that tells you to cancel, which is as important as the one that tells you to scale

Good answer: defined evaluation, a rollback path, and written exit criteria.

Red flag: "we'll productionize it after the demo."

Put it on one page

Before kickoff, turn the answers into a short brief that everyone signs off on. Something as light as this works:

project: support-ticket-triage
problem: Tier-1 agents spend too long routing tickets
success_metric:
  baseline: <median time to first routing today>
  target: <number the team commits to>
  measured_by: <dashboard or report>
data:
  sources: [ticketing system, knowledge base]
  owner: <named person>
  contains_pii: true
integration:
  systems: [ticketing API, SSO]
  auth: service account, least privilege
ownership:
  product_owner: <name>
  on_call: <team>
  human_review: low-confidence routes
governance:
  data_residency: <region>
  audit_log: required
  approved_models: [<list>]
cost:
  per_request_budget: <amount>
  monthly_ceiling: <amount>
pilot_to_prod:
  eval_set: <size and source>
  rollback: feature flag
  stop_criteria: <what makes us cancel>

The blanks are the point. Every <placeholder> you can't fill in is a risk you've found for free.

How to use this list

Run it as a one-hour workshop with engineering, security, and the business owner in the same room. If you can't answer most of the seven, that isn't a reason to abandon the project. It's a sign the next step is discovery, not development.

The teams that scale AI successfully tend to be the ones that did the boring questions first.

Which of these has caught your team off guard? Share it in the comments.

The Shift From Manual Patching to AI-Driven Vulnerability Resolution

Sam Amderson — Thu, 29 Oct 2026 11:21:46 +0000

Your scanner found 340 vulnerabilities this morning. Your team fixed 6 last sprint.

That gap is the real security problem in most engineering orgs. Finding vulnerabilities stopped being the hard part years ago. Fixing them is where teams fall behind.

Manual patching was built for a world with fewer dependencies, slower release cycles, and smaller attack surfaces. That world is gone. This post looks at why manual patching breaks down, what AI-driven vulnerability resolution actually does, and how to adopt it without handing your codebase to a black box.

Why Manual Patching Breaks Down

Manual patching follows a familiar loop: a scanner raises an alert, someone creates a ticket, the ticket waits in the backlog, and eventually an engineer upgrades the package, fixes whatever breaks, and runs the tests.

Every step in that loop depends on a person, and the volume keeps growing.

Dependency trees are deep. A typical app pulls in hundreds of transitive packages. Most vulnerabilities live in code you never chose directly.
Upgrades break things. A security fix may only exist in a newer major version, which can come with API changes and refactoring work.
Testing is the bottleneck. Every upgrade needs verification, and manual QA cycles don't scale with alert volume.
Context switching is expensive. Engineers pulled off roadmap work to patch lose hours getting back into flow.
Alert fatigue sets in. When the backlog never shrinks, teams start ignoring it, which is exactly when a critical issue slips through.

The result is a backlog that grows faster than it shrinks, and a remediation process that only speeds up during emergencies.

What AI-Driven Vulnerability Resolution Actually Means

Traditional scanners report. AI-driven tools resolve. The difference is how far the automation goes after detection.

A typical AI-driven resolution flow looks like this:

Detect vulnerabilities across application code, direct packages, and transitive dependencies.
Prioritize by severity, exploitability, and whether the vulnerable code path is actually reachable.
Upgrade only the affected packages to safe versions.
Resolve the code changes the upgrade requires, such as updated function calls after an API change.
Verify the fix by running unit, integration, and regression tests.
Propose the change as a pull request with evidence attached: what was found, what changed, and what passed.

A human then reviews and approves the PR. The tedious parts are automated, while the judgment stays with people.

What This Looks Like in Practice

Here's a simple dependency upgrade. Older lodash versions have known prototype pollution vulnerabilities that were fixed in later 4.17.x releases:

  "dependencies": {
    "express": "^4.21.2",
-   "lodash": "4.17.15"
+   "lodash": "4.17.21"
  }

That one's easy. The harder cases are vulnerabilities in your own code, where the fix needs a code change rather than a version bump. A classic example is SQL built from user input:

  def find_orders(customer_id):
-     sql = f"SELECT * FROM orders WHERE cid={customer_id}"
-     return db.execute(sql)
+     sql = "SELECT * FROM orders WHERE cid = %s"
+     return db.execute(sql, (customer_id,))

An AI-driven tool can generate both kinds of change, run your test suite against them, and open a PR with the results. The engineer's job shifts from writing the fix to reviewing it.

Where Humans Still Matter

AI-driven resolution doesn't mean removing people from the loop. It means putting them in the right place in it.

Approving changes: Every fix should go through code review, especially in critical services.
Major version upgrades: Breaking changes in frameworks often need architectural judgment, not just mechanical edits.
Business logic: If a fix changes behavior, someone who understands the domain has to confirm it's correct.
Policy decisions: Humans decide which repos allow auto-merge, which require approval, and which issues can be accepted as risk.

Automation handles the volume. People handle the judgment.

How to Adopt It Without Losing Control

You don't need to switch your whole organization overnight. A gradual rollout builds trust:

Start with one repository that has good test coverage. AI-generated fixes are only as trustworthy as the tests that verify them.
Begin with patch and minor upgrades. Save major version upgrades for later, once you trust the process.
Require PRs, not direct commits. Every change should be reviewable and reversible.
Measure mean time to remediate (MTTR). Track how long vulnerabilities stay open before and after adoption.
Expand gradually. Add repos and broaden the scope of upgrades as results hold up.

Common Pitfalls to Avoid

Trusting fixes without tests. If your coverage is thin, invest there first.
Auto-merging major upgrades. Keep a human gate on anything with breaking changes.
Ignoring transitive dependencies. That's where much of the risk actually lives.
Skipping the audit trail. Record what was found, what changed, and who approved it. You'll need it for compliance and incident reviews.

The Bottom Line

Manual patching isn't wrong. It just doesn't scale to the size of modern dependency trees. The shift to AI-driven vulnerability resolution is a shift from chasing alerts to reviewing tested fixes.

Teams that make it well keep humans in control, start small, and let their test suites do the heavy lifting.

Over to you: How does your team handle the vulnerability backlog today? Fully manual, Dependabot-style automation, or something more advanced? Share in the comments.

If you found this useful, follow for more practical posts on security, DevOps, and AI in software delivery.

This article was written by Xccelera AI team with AI-assisted editing. All content has been reviewed for accuracy.

Human-in-the-Loop Approval Matrix for AI Agent Actions

Sam Amderson — Mon, 26 Oct 2026 09:45:20 +0000

Your AI agent just deleted a production table. The first question in the postmortem won't be about the model. It will be: who decided this agent was allowed to do that alone?

Most production failures with AI agents trace back to that one unanswered question. A human-in-the-loop approval matrix answers it in advance by tying every agent action to three things:

A risk tier
A named approver
An escalation path

The result is that low-risk work stays fast, and costly or irreversible actions reach accountable people. Every decision also leaves a record that security, audit, and engineering leaders can inspect at any time, so no one has to rebuild the story after the fact.

Here's how to build one, step by step.

Step 1: Classify Every AI Agent Action by Risk and Reversibility

A human-in-the-loop approval matrix is only as good as the inventory behind it. Before anyone is named as an approver, list what each agent can actually do: read a record, draft a message, change a configuration, release a payment, delete data.

Teams that skip this step guard the loud actions and miss the quiet ones. That's why teams building governed enterprise AI programs usually start here. Every later rule depends on having a complete and honest list of actions.

Agent Permission Tiers: From Read-Only to Irreversible

Permission tiers give the matrix its rows. Each tier groups actions that would have the same consequence if the agent got them wrong, so approvers review by impact, not by tool name.

Four tiers cover most enterprise deployments. The default control for each is a starting point that risk owners should tune.

Tier 0, read-only: Querying a knowledge base. Default control: runs autonomously and is logged.
Tier 1, reversible write: Drafting a ticket or updating a staging record. Default control: runs autonomously, with sampled review.
Tier 2, business-impacting: Changing customer-facing settings. Default control: a single approval before execution.
Tier 3, irreversible or regulated: Deleting production data, releasing a payment, or granting access. Default control: dual approval, and never auto-approved on timeout.

Scoring Blast Radius, Data Sensitivity, and Financial Exposure

Tier placement should come from a repeatable score, not from a debate in every meeting. Rate each action on three factors:

Blast radius: How many users, systems, or records one mistake can touch.
Data sensitivity: Whether the action reads or writes personal, financial, or regulated data.
Financial exposure: The cost of the worst realistic outcome, including cleanup and customer impact.

Then place the action in the highest tier that any single factor reaches. Scoring on the maximum rather than the average stops a cheap but dangerous action from hiding in a low tier.

Step 2: Set Autonomy Thresholds for Which Agent Actions Run Alone

Autonomy thresholds turn tiers into rules an agent can follow at runtime. A threshold states the exact condition under which an action can proceed without a person.

If a threshold isn't machine-checkable, it will quietly turn into a suggestion. So encode these checks into the agent's execution path rather than leaving them in a policy document.

A workable set of thresholds usually includes four checks:

The action belongs to a tier that allows autonomous execution.
The agent's own confidence or validation score clears the agreed floor.
The target system, account, or dataset is on the approved list.
Spend, volume, or record counts stay under a per-run limit.

If any one check fails, the action pauses for approval. Each threshold also needs an owner who can raise or lower it, along with a change log that records why.

Start conservative. Most teams can widen autonomy once a review period shows clean results. Narrowing it after an incident costs trust, and that trust takes much longer to rebuild.

Step 3: Assign Approval Authority in a Risk-Based Approval Workflow

Approval authority fails when it sits with whoever happens to be online. A risk-based approval workflow assigns authority according to the kind of risk an action carries:

Engineering owns technical correctness.
Security owns access and exposure.
Business owners own financial and customer impact.

Each row in the matrix names a role, not a person, so coverage holds up through vacations and reorganizations.

Single Approver, Dual Approval, and Committee Review

The review model should scale with the consequence. Heavier models slow delivery, so save them for actions where the downside justifies the delay.

Single approver: For Tier 2 changes with a clear rollback. The approver is typically the domain owner.
Dual approval: For Tier 3 actions that touch money or access. The approvers are typically the domain owner plus security.
Committee review: For new action types or policy exceptions. The approver is typically a cross-functional risk group.

Time Limits and Fallback Approvers

Every approval request needs a clock. Set a response window for each tier, name a fallback approver, and decide in advance what happens when the window expires.

For Tier 3 actions, the answer should be that the action stays blocked and the request escalates. Silence should never count as consent.

Without this rule, approval queues become bottlenecks, and bottlenecks tempt teams to loosen controls under delivery pressure.

Step 4: Define Escalation Rules for AI Agents

Escalation rules cover the moments a matrix can't predict. An agent will eventually meet a situation that no row describes, and the safe default is to stop and ask rather than guess.

Good escalation rules are specific about three things: the triggers, where the request goes, and what the agent does while it waits.

One rule matters above the rest:

An action missing from the matrix is a Tier 3 action until a human classifies it.

Common triggers that should route a request to a person include:

Validation or confidence scores fall below the agreed floor.
Two policies give conflicting instructions for the same action.
The request targets a system or dataset outside the approved list.
Repeated retries suggest the agent is looping rather than making progress.

Every escalation should arrive with full context: the proposed action, the agent's reasoning, the inputs it used, and the tier that triggered the review. Approvers who have to reconstruct context from scratch either approve slowly or approve blindly.

Step 5: Build an Audit Trail and Review the Matrix Regularly

An approval matrix without records is a policy document, not a control. An audit trail for agent decisions should capture:

The requested action and its tier
The approver and their decision
The timestamp
The outcome after execution

These fields let security teams answer an incident question in minutes. They also let auditors confirm that the matrix was actually followed, not just written down.

Keep the Matrix Alive

The matrix needs a review cadence, and quarterly is a sensible start. Look at approval rates, override reasons, and near misses:

An action that gets approved unchanged every time is a candidate for a lower tier.
An action that keeps generating overrides may need tighter thresholds.

Human oversight for AI agents works best as a living system that tracks real behavior. Each review should end with concrete tier changes, not a summary slide.

Putting the Matrix Into Production

Writing the matrix is the easy part. Running it across many agents, teams, and systems is where programs stall. Approvers multiply, thresholds drift, and records scatter across tools.

A few practices keep it working at scale:

Enforce the matrix in code, not in a wiki. The checks should run in the agent's execution path, so every action passes through them.
Route approvals to one place. Approvers shouldn't have to hunt across Slack, email, and tickets to find pending requests.
Store decisions with the action log. Approvals that live next to the actions they cover make audits and incident reviews much faster.
Widen autonomy on evidence. Move an action to a lower tier only after the review data supports it.

The Bottom Line

Whether you build your own tooling or evaluate a platform, ask one direct question:

Can every consequential agent action be traced to a tier, an approver, and a recorded decision?

If the answer is yes, autonomy can grow safely. If it's no, the risk is simply moving faster.

Over to you: How does your team decide which agent actions need human approval today? Share your approach in the comments.

If this was useful, follow for more practical guides on building and governing AI agents in production.

This article was written by our team with AI-assisted editing. All content has been reviewed for accuracy.