1. Reliability is an end-to-end property If a workflow has n required steps and each step succeeds independently with probability p, then: P(all steps succeed) = p^n For p = 0.99: Required steps Probability of no step failure 1 99.0% 5 95.1% 10 90.4% 20 81.8% 50 60.5%

This is a deliberately simplified model, not an empirical benchmark. Production workflows have unequal and correlated failure rates; retries, fallbacks, and human intervention change completion probabilities. It is still a useful way to understand why local reliability isn't enough. 2. Model the workflow as a state machine An agent should not depend on a growing chat transcript as its only record of execution. Consider this workflow: Intake -> Validate input -> Retrieve customer record -> Evaluate request -> Request approval (if needed) -> Update CRM -> Notify customer -> Close case Each step should have an explicit status, such as pending, running, completed, failed, or waiting_for_approval. The runtime should persist step inputs, validated outputs, timestamps, and the identity under which actions execute. A simple Python-style representation: from dataclasses import dataclass, field

@dataclass class WorkflowState: run_id: str completed: set[str] = field(default_factory=set) outputs: dict = field(default_factory=dict) status: str = "running"

def record_success(self, step_id: str, result):
    self.outputs[step_id] = result
    self.completed.add(step_id)

This is an illustrative in-memory structure. A real implementation must persist updates durably and handle concurrent workers safely. 3. Treat reads and writes differently Retrying a failed read is often straightforward. Retrying a write is not. Suppose the agent calls an email API. The provider accepts the message, but the network connection drops before the success response arrives. From the caller's perspective, the outcome is ambiguous. A naive retry can send the email twice. Use a stable operation identifier when the provider supports idempotency: operation_id = f"{run_id}:notify-customer"

send_notification( customer_id=customer_id, message=message, idempotency_key=operation_id, ) Important: The example assumes send_notification and its provider honor the idempotency key. Adding the parameter alone does not guarantee deduplication. When the provider lacks this feature, use an outbox/deduplication record and reconcile ambiguous outcomes before retrying. 4. Put validation between model reasoning and side effects Model output should be treated as a proposal, not authorization. Before executing a write, check:

1. Is the output schema valid?

2. Is the supporting evidence current and relevant?

3. Does the execution identity have the required permission?

4. Is the action within policy and budget limits?

5. Does the risk level require human approval? For example: def authorize_action(action, context): if not action.schema_valid: return "reject" if not context.has_required_evidence: return "needs_more_information" if not context.identity_can_execute(action): return "reject" if context.requires_approval(action): return "wait_for_approval" return "allow" This is a conceptual guardrail, not a complete authorization implementation. In production, enforcement belongs in the execution layer—not merely in the prompt.

6. Define a recovery policy for every step A practical step definition should specify more than a tool name: step: update_crm kind: write timeout_seconds: 15 max_attempts: 3 retry_on:

• rate_limit

• transient_unavailable requires:

• validated_customer_id

• approved_change on_ambiguous_result: reconcile_before_retry on_terminal_failure: escalate The exact schema will depend on your orchestrator. The point is to make operational behavior explicit. Some failures should be retried with backoff. Others should be escalated immediately. Invalid permissions, missing approvals, and unsupported actions are not transient failures.

1. Observe complete runs, not isolated calls Useful production metrics include:

• End-to-end completion rate: Did the user-requested outcome happen correctly?

• Step failure rate: Which tool or dependency fails most often?

• Retry and recovery rate: How often did a run need repair?

• Duplicate side-effect count: Did an action happen more than once?

• Escalation rate: How frequently did a human need to intervene?

• Time and cost per successful run: How much did dependable execution require? Correlate logs, traces, approvals, and audit events with a single run_id. A successful model response is not equivalent to a successful business process.

1. Use orchestration to enforce boundaries As workflows grow, a robust runtime needs to coordinate state, policies, confidence checks, approvals, budgets, and audit records. These responsibilities should not be left to the model's discretion. At Nuroen, we focus on governed agent orchestration and execution controls, including human approvals and auditability. The underlying principle applies regardless of platform: the runtime must own reliability, not just the prompt. Final checklist Before shipping a multi-step agent, test a timeout after a successful write, a stale retrieval, a permission denial, a failed approval, an unavailable downstream API, and a resumed run after process restart. If your workflow only works when every step succeeds the first time, it's still a prototype. What recovery pattern has worked best in your agent stack: checkpointing, durable execution, idempotent tools, or human-in-the-loop escalation?

Building an AI agent has never been easier.

Connect a language model, configure a few tools, define a workflow, and give it a task.

Within minutes, you might have an agent that retrieves information, updates records, communicates with external systems, and makes decisions.

The demonstration works.

Everyone is impressed.

Then the agent reaches production.

An API times out. A connector loses authorization. A database returns incomplete information. An external service becomes unavailable halfway through a workflow.

Suddenly, the same agent that performed flawlessly in testing cannot complete a basic operation.

The problem isn't necessarily the intelligence of the agent. It's the reliability of the system surrounding it.

And this is where failure recovery becomes essential.

The Hidden Problem With Agentic Automation

Traditional automation usually follows predefined execution paths.

If a step fails, the system can return an error, retry the operation, or trigger an exception handler.

Agentic automation introduces additional complexity.

An AI agent may dynamically select tools, retrieve information, reason about results, and determine subsequent actions.

That flexibility creates new failure scenarios.

Consider a simple enterprise workflow:

User Request
     |
     v
AI Agent
     |
     v
Retrieve Customer Information
     |
     v
Update CRM
     |
     v
Generate Report
     |
     v
Send Email

Under ideal conditions, this workflow is straightforward.

But what happens if the CRM update succeeds and the email service fails?

Should the agent restart the entire workflow?

Should it retry only the email operation?

Should it notify a human?

Or should it stop execution?

Without an explicit recovery strategy, the agent may make an unsafe decision—or simply fail without a useful explanation.

Why Retrying Isn't Always Recovery

One common approach to handling failures is automatic retry.

An API call fails.

The system waits.

It tries again.

This works for certain transient failures, such as temporary network interruptions.

But not every failure should trigger a retry.

Imagine an agent processing a customer refund.

The payment API processes the refund successfully, but the response times out.

The agent interprets the timeout as a failed operation.

It retries.

Without safeguards, the customer could receive two refunds.

The underlying issue is that the agent cannot distinguish between:

• An operation that failed before execution.

• An operation that succeeded but returned no confirmation.

• An operation that partially completed.

• An operation that should never be repeated automatically.

Production recovery therefore requires more than retries.

It requires execution awareness, state management, idempotency, and defined recovery policies.

Five Capabilities Every Production Agent Needs

1. Failure Detection

An agent should distinguish between different classes of failure.

Examples include:

• Temporary API unavailability.

• Authentication or permission failures.

• Invalid or incomplete data.

• Tool execution timeouts.

• Policy violations.

• Unexpected workflow outcomes.

These failures require different responses.

A temporary network error may justify retrying.

An expired authorization token may require reconnecting a service.

A policy violation should block the action.

Treating every failure identically creates unnecessary risk.

2. Controlled Retry and Recovery

Retry mechanisms should operate within defined boundaries.

A production workflow might use:

Tool Execution
      |
      v
Did It Succeed?
   /       \
 Yes        No
  |          |
Continue   Classify Failure
             |
             v
       Retry Permitted?
          /       \
        Yes        No
         |          |
    Retry Within   Escalate
       Limits

A reliable retry strategy should consider maximum attempts, backoff intervals, timeouts, and whether an operation is safe to repeat.

For actions with external side effects, idempotency keys or equivalent safeguards can help prevent duplicate execution.

3. Human-in-the-Loop Escalation

Some failures require human judgment.

Consider an AI agent responsible for IT operations.

It detects a production service failure and proposes restarting a critical component.

The action may be technically valid.

But should it execute automatically?

Not necessarily.

A controlled workflow could follow:

Agent Detects Failure
         |
         v
Proposes Remediation
         |
         v
Policy Evaluation
         |
         v
Human Approval Required
         |
      /     \
 Approved   Rejected
    |          |
 Execute    Stop / Escalate

The important principle is straightforward:

An agent should not gain additional authority simply because something went wrong.

Human approval provides a controlled path for consequential decisions.

4. Budget and Execution Limits

Failures can create expensive execution loops.

An agent may repeatedly call the same model, retrieve the same information, or invoke a failing API.

Without limits, a single request can consume disproportionate resources.

Production agents should have controls for:

• Maximum tool calls.

• Retry attempts.

• Execution duration.

• Token or credit consumption.

• Escalation when limits are reached.

An agent that cannot complete a task within its permitted resources should stop safely rather than continue indefinitely.

5. Auditability and Execution Traceability

When an agent fails, engineering teams need to understand exactly what happened.

A useful execution record should answer:

• What triggered the workflow?

• Which tools were called?

• Which operations succeeded?

• Where did execution fail?

• What recovery action was attempted?

• Was human approval required?

• What was the final outcome?

Without this information, debugging becomes guesswork.

For enterprise environments, traceability also supports operational accountability and compliance investigations.

What a Production Recovery Architecture Looks Like

A more resilient agent execution model separates reasoning from execution controls.

           User Request
                |
                v
          AI Orchestrator
                |
                v
         Context Retrieval
                |
                v
          Agent Planning
                |
                v
         Policy Evaluation
                |
                v
          Tool Execution
                |
          +-----+-----+
          |           |
       Success      Failure
          |           |
          |           v
          |     Failure Classification
          |           |
          |     Recovery Decision
          |           |
          |      +----+----+
          |      |         |
          |   Safe Retry  Escalation
          |      |         |
          |      v         v
          |   Validate   Human Review
          |      |         |
          +------+---------+
                 |
                 v
          Audit & Outcome

The objective is not to eliminate every possible failure.

That is unrealistic in distributed enterprise systems.

The objective is to ensure failures produce controlled, explainable, and bounded outcomes.

How Nuroen Approaches Controlled Agent Execution

At Nuroen, we believe enterprise AI agents need more than reasoning capabilities and tool connectivity.

They need governance built into execution.

Nuroen is designed around a unified approach to building, governing, orchestrating, and deploying AI agents.

Its execution model emphasizes several important controls.

Scope and knowledge boundaries

Agents operate within defined permissions and available knowledge sources.

Confidence-aware decisions

When an agent lacks sufficient confidence, execution can be restricted or escalated according to configured controls.

Policy enforcement and human approval

Sensitive actions can be subject to policy checks and human-in-the-loop decisions before execution.

Budget governance

Execution budgets help keep agent activity within operational limits.

Auditability

Execution traces provide visibility into actions, decisions, and outcomes.

These controls establish a foundation for predictable behavior when workflows encounter unexpected conditions.

A complete failure-recovery design should additionally account for retry safety, idempotency, state preservation, and resumption behavior appropriate to each connected system.

The goal is not unrestricted autonomy.

The goal is autonomy that operates within boundaries an enterprise can understand and control.

The Difference Between a Demo and a Production System

A demo proves that an agent can complete a task when the environment behaves as expected.

Production readiness requires answering much harder questions.

What happens when a dependency fails?

What happens when an action partially succeeds?

Can the system avoid repeating consequential operations?

Can it stop when its execution budget is exhausted?

Can a human intervene before a risky action?

Can engineers reconstruct what happened afterward?

These are not secondary concerns.

They are fundamental engineering requirements.

Final Thoughts

The next phase of enterprise AI adoption will not be defined solely by how many tools an agent can access or how many tasks it can perform autonomously.

It will also be defined by how reliably those agents operate when real-world systems behave unpredictably.

Because in production, failure is inevitable.

Uncontrolled failure is not.

At Nuroen, we're building toward a model of enterprise AI where autonomy, governance, and operational accountability work together.

Explore Nuroen: https://www.nuroen.com/

Discussion: What's the most difficult failure scenario you've encountered while building or deploying an AI agent?

Tags: AI Agents, Agentic AI, System Design, LLM, DevOps

AI agents are becoming increasingly capable.

They can retrieve information, call APIs, interact with enterprise applications, update records, and coordinate multi-step workflows.

But there's a fundamental problem that successful demos rarely expose.

What happens when an AI agent fails halfway through a business-critical workflow?

Not every failure is a harmless error message.

Sometimes an action has already happened. Sometimes a system returns incomplete information. And sometimes an agent attempts an operation that should never have been permitted.

Without an appropriate recovery architecture, a small technical failure can turn into a much larger operational problem.

Let's examine why failure recovery matters and how to design agent workflows that remain controlled when things go wrong.

1. Why successful agent demos aren't enough

Consider an enterprise AI agent responsible for processing customer requests.

Its workflow looks straightforward:

Step 1: Retrieve customer information from a CRM.

Step 2: Validate customer details.

Step 3: Update the relevant customer record.

Step 4: Send a confirmation email.

Step 5: Record the outcome in an audit log.

During testing, each step completes successfully.

The agent appears production-ready.

Now consider a different execution.

The CRM accepts the update but the API response times out.

The agent doesn't know whether the action succeeded.

A naive retry could repeat the operation.

Or consider another scenario: the agent encounters a permissions error, but its workflow treats every failure as something that should be retried.

Neither situation requires a more intelligent language model.

Both require better execution control.

2. The five failure categories every agent architect should understand

Production agents interact with systems that can fail in different ways.

Treating all failures identically is one of the easiest ways to create unreliable automation.

These aren't interchangeable scenarios.

A temporary network failure might justify a retry.

A policy violation should not.

An uncertain write may require inspecting the target system before deciding what to do next.

The recovery decision needs to reflect the actual risk.

3. Why retries alone aren't a recovery strategy

Retries are useful, but only under the right conditions.

Imagine an agent that creates a financial transaction and receives no response from the destination service.

It cannot safely assume the transaction failed.

Sending the same request again might create a duplicate transaction.

This introduces an important concept:

Idempotency.

An idempotent operation produces the same intended result even when repeated.

For workflows that change external state, developers should consider mechanisms such as:

• Unique operation identifiers to prevent duplicate writes.

• Execution checkpoints to record completed steps.

• State reconciliation before retrying uncertain operations.

• Compensating actions when a completed change needs to be reversed.

• Human intervention when the system cannot establish a safe recovery path.

Retries should also be bounded.

Unlimited retries can consume budgets, overload APIs, and turn a temporary issue into a prolonged operational incident.

A robust recovery strategy must know not just how to retry, but whether retrying is appropriate.

4. A practical failure recovery architecture

A production agent can be designed around five execution stages.

Detect → Classify → Contain → Recover → Audit

Detect

Observe tool responses, execution outcomes, validation failures, and authorization problems.

A failure signal should include enough context to determine which action was attempted and what is known about its result.

Classify

Determine whether the failure is transient, permanent, policy-related, or associated with an uncertain external state.

This classification drives the next decision.

Contain

Prevent the problem from spreading through the workflow.

For example, an agent should not send a customer confirmation email if it cannot establish whether the requested account update succeeded.

Recover

Select an appropriate recovery path.

That may involve a bounded retry, an alternative route, state reconciliation, a compensating operation, or escalation to a human reviewer.

Audit

Record what failed, what the system knew, which recovery decision was made, and whether subsequent execution was authorized.

This information becomes essential for debugging, compliance reviews, and continuous improvement.

A simple decision flow

The important architectural principle is straightforward:

An agent should not treat every failure as permission to keep going.

5. Why governance belongs inside execution

Traditional software systems often treat governance and execution as separate concerns.

AI agents make this separation more difficult.

An agent can dynamically choose tools, use retrieved information to plan actions, and interact with systems that have different permissions and risk levels.

That means governance cannot exist only as a policy document or a pre-deployment checklist.

It needs to be enforced during execution.

Consider an agent that attempts to retrieve sensitive customer information and send it to an external service.

Even if the underlying API call is technically valid, the action might violate organizational policy.

A reliable agent architecture needs to evaluate more than technical success.

It must also consider:

Scope: Is this action within the agent's permitted responsibilities?

Confidence: Is there sufficient evidence to proceed?

Policy: Does the action comply with organizational rules?

Human approval: Does the action require explicit authorization?

Budget: Is execution within established resource limits?

Auditability: Can the organization reconstruct what happened?

These controls help contain risk before an execution failure becomes a business incident.

6. How we're approaching this at Nuroen

At Nuroen, we believe enterprise AI agents need more than powerful models and access to tools.

They need an execution environment designed around control.

Nuroen brings together agent creation, orchestration, governance, and deployment in one enterprise agentic platform.

Our runtime governance approach includes:

Scope and knowledge boundaries

Agents operate within defined responsibilities and permitted knowledge sources.

Confidence-based checks

Execution decisions can be evaluated against confidence requirements before proceeding.

Policy enforcement and human approvals

Actions that require authorization can be routed through human-in-the-loop controls instead of executing without oversight.

Budget controls

Organizations can define execution limits to help prevent uncontrolled resource consumption.

Auditable execution

Agent activities and governance decisions can be recorded to support visibility and accountability.

These controls are important building blocks for resilient enterprise automation.

However, governance alone is not a substitute for application-level recovery.

Developers still need to design appropriate retry rules, idempotency protections, reconciliation logic, and recovery paths for the systems their agents interact with.

The strongest approach combines safe agent execution with explicit workflow recovery engineering.

7. Reliability is the real production benchmark

A successful demo proves that an agent can complete a task under favorable conditions.

Production readiness requires more.

It requires answering difficult engineering questions:

Can the workflow safely stop after partial execution?

Can it distinguish a failed operation from an uncertain result?

Can it prevent duplicate side effects?

Can an authorized person inspect and approve sensitive decisions?

Can operators understand what happened after an incident?

And can recovery happen without introducing additional risk?

These are the questions that determine whether an agent can be trusted inside real enterprise systems.

Final thoughts

Failure recovery is not an optional enhancement for production AI agents.

It is part of the execution architecture.

As agents move from answering questions to taking actions across enterprise systems, the consequences of failures become more significant.

The goal should never be unlimited autonomy.

The goal should be controlled execution, deliberate recovery, and clear accountability.

At Nuroen, we're building toward that future: enterprise AI agents that operate within defined boundaries, with governance embedded into execution.

Because the measure of a production agent isn't just what it can accomplish when everything works.

It's how safely the system responds when something doesn't.

Explore Nuroen: https://www.nuroen.com/

What recovery patterns are you using in your AI agent workflows? Are you relying on retries, checkpoints, human approvals, or something else?

Let's discuss.

Suggested Hashnode tags: AI, AgenticAI, SoftwareArchitecture, DevOps, ArtificialIntelligence

Give it a model. Connect a few tools. Add enterprise knowledge. Define a workflow.

Run the demo.

It works. 🎉

But there’s a dangerous assumption hiding here:

“It worked” ≠ “It’s ready for production.”

The moment an agent moves from a controlled demo into a real environment, the question changes from:

Can the agent complete the task?

to:

Can we trust the agent to complete the task under real-world conditions?

That requires a very different kind of testing.

Think of production readiness as a series of gates

Before an agent can act in a production environment, it should prove that it can operate within clearly defined boundaries.

A simplified architecture might look like this:

User Request
     ↓
    Agent
     ↓
┌─────────────────────┐
│ 1. Scope & Context  │
├─────────────────────┤
│ 2. Confidence       │
├─────────────────────┤
│ 3. Policy           │
├─────────────────────┤
│ 4. Human Approval   │
├─────────────────────┤
│ 5. Budget           │
├─────────────────────┤
│ 6. Audit            │
└─────────────────────┘
     ↓
Execute Action

If the agent fails a critical gate, execution should stop, retry safely, or escalate.

1. Scope: Does the agent know its boundaries?

An agent shouldn't have unlimited freedom simply because it has access to a tool.

Imagine an IT operations agent.

It might be allowed to:

✓ Read logs
✓ Search documentation
✓ Inspect incidents
✓ Query monitoring systems

But not automatically:

✕ Delete production resources
✕ Modify IAM permissions
✕ Restart critical infrastructure

Production agents need explicit boundaries around what they can read, decide and execute.

2. Grounding: Is it working from the right information?

Agents often make decisions using retrieved knowledge.

But retrieval introduces another failure surface.

What happens if the information is:

• outdated?

• incomplete?

• irrelevant?

• contradictory?

• unavailable?

The agent should be tested against bad context—not just perfect context.

A useful question is:

What does the agent do when it doesn't know enough?

Sometimes the correct behavior is not generating another answer.

It's stopping.

3. Confidence: Does the agent know when not to act?

Autonomy without uncertainty handling is risky.

A production agent should have a defined response to uncertainty.

High confidence
      ↓
Continue

Medium confidence
      ↓
Retrieve / validate

Low confidence
      ↓
Escalate

The exact thresholds depend on the workflow.

But the principle is simple:

Uncertainty should change agent behavior.

4. Policy: Is the action actually allowed?

An agent can produce a technically correct action that violates organizational policy.

For example:

“Restart the production database.”

Technically possible?

Maybe.

Authorized?

That's a different question.

Policy checks can evaluate things like:

Agent
  ↓
Proposed action
  ↓
Policy evaluation
  ↓
Allowed ──────────→ Execute
  │
  └── Restricted → Approval / Block

This separates capability from permission.

5. Human approval: Does the right person still have the veto?

Not every action deserves the same level of autonomy.

Reading a dashboard and changing production infrastructure have very different consequences.

Sensitive actions might require:

Agent proposes → Human reviews → Human approves → Agent executes

The important part is that approval happens before the consequential action, not after it appears in an audit log.

6. Budget: Can the agent control its own resource consumption?

Agent workflows can expand quickly.

One request might trigger:

Planning
→ Retrieval
→ Model call
→ Tool call
→ Validation
→ Retry
→ Another tool
→ Another model call

Without limits, an execution loop can become expensive.

Production testing should therefore include:

• execution limits

• retry limits

• token or credit budgets

• tool-call ceilings

• timeout behavior

The agent needs to know not only what it can do, but how far it can go.

7. Failure handling: What happens when the happy path disappears?

This may be one of the most important tests.

Don't only test:

“Can the agent successfully execute this workflow?”

Test:

“What happens when every dependency starts breaking?”

Simulate:

API timeout
Connector unavailable
Missing permission
Malformed response
Stale knowledge
Tool returns partial data
Approval denied
Budget exhausted
Model uncertainty

A production-ready agent shouldn't require everything around it to behave perfectly.

8. Auditability: Can you reconstruct what happened?

After an agent executes an action, someone may eventually ask:

Why did it do that?

You should be able to reconstruct the chain:

Request
   ↓
Retrieved context
   ↓
Agent decision
   ↓
Policy evaluation
   ↓
Human approval
   ↓
Tool execution
   ↓
Result

Who requested it?

What information did the agent use?

Which action did it propose?

Which policy allowed it?

Who approved it?

What changed?

The answers shouldn't depend on someone's memory.

They should be part of the system.

The real production test

The most important test isn't whether an agent succeeds when everything goes right.

It's whether it behaves correctly when something goes wrong.

That's why production readiness is less about creating a perfect autonomous agent and more about building controlled autonomy.

At Nuroen, this maps closely to the broader philosophy of treating agents as governed infrastructure rather than isolated AI features: agents, connectors and knowledge operate as one system, with approval, audit and control treated as first-class capabilities. :chatgpt-content-reference{index="0"}

Before you deploy your next agent, ask:

Can it complete the task?

Good.

Now ask:

Does it know what it's allowed to do?

Does it stop when confidence is low?

Can a human veto sensitive actions?

Does it stay within budget?

Can it survive failures safely?

Can we reconstruct every important decision afterward?

If those questions haven't been tested, the agent may be demo-ready.

But production readiness is a different test.

Alternative clickbait-style titles

Your AI Agent Passed the Demo. It Might Still Fail Production.

Before You Deploy an AI Agent, Make It Pass These 8 Tests

The AI Agent Production Checklist Nobody Talks About

Your Agent Works. Here’s Why You Still Shouldn’t Deploy It.

A Working AI Agent Is Not a Production-Ready AI Agent

#AIAgents #AgenticAI #AIEngineering #AIGovernance #LLM #EnterpriseAI #Automation #DevOps

Today, chatbots, RAG applications, workflows, copilots, and autonomous systems are often grouped under the same label: AI agents.

They aren't the same.

The useful distinction is simple:

Who decides what happens next?

1. AI Assistant — Helps You Decide

An AI assistant primarily responds to a human request.

User → AI → Response → Human Decision

Typical examples include:

• Summarizing documents

• Answering questions

• Drafting content

• Analyzing information

• Recommending actions

The AI provides intelligence, but the human decides what happens next.

2. Automation — Follows a Defined Path

An automation executes a predefined sequence.

Trigger
   ↓
Rules
   ↓
Actions
   ↓
Result

For example:

New support ticket
       ↓
    Classify
       ↓
     Assign
       ↓
 Send notification

The workflow might use an LLM for classification or extraction, but the overall path is still predetermined.

AI-powered doesn't automatically mean autonomous.

3. Autonomous Agent — Decides and Adapts

An autonomous agent operates around a goal rather than simply following one fixed sequence.

Goal
 ↓
Reason
 ↓
Plan
 ↓
Act
 ↓
Observe
 ↓
Adapt
 ↺

Consider the instruction:

“Resolve this production incident.”

An agent could potentially:

1. Investigate logs

2. Check monitoring systems

3. Retrieve relevant documentation

4. Determine the next action

5. Execute an approved operation

6. Observe the result

7. Decide whether another action is necessary

The important part isn't simply that the system uses an LLM.

It's that the next action can be determined during execution based on the current state of the environment.

The Real Difference

A useful mental model is:

This distinction becomes especially important in enterprise environments.

Giving an agent autonomy doesn't mean giving it unlimited access.

A production agent may need:

• Permission controls

• Tool restrictions

• Policy enforcement

• Human approvals

• Budget limits

• Execution boundaries

• Audit trails

So instead of asking:

“Is this an AI agent?”

A better engineering question might be:

“What can this system decide when the expected path changes?”

If the answer is nothing, you may be looking at an automation.

If it can evaluate the situation, choose another action, observe the result, and adapt within defined boundaries, you're much closer to an agentic system.

How do you define the minimum capability required for something to be called an AI agent?

#AI #AIAgents #AgenticAI #LLM

AI agents have become one of the most common terms in software engineering.

But there's a problem.

Almost everything involving an LLM is now being called an agent.

A chatbot with tool calling? Agent.

A RAG application? Agent.

An automated workflow with an LLM step? Agent.

A scheduled task that generates an email? Agent.

At some point, the word starts losing technical meaning.

So here's a question worth asking:

What actually makes an AI system an agent?

AI-powered doesn't automatically mean agentic

Consider this workflow:

User Request ↓ LLM ↓ Extract Information ↓ Call API ↓ Return Result

There's clearly AI involved.

But the execution path is predetermined.

The developer decides:

what happens first which tool gets called what happens afterward when the workflow ends

The LLM might make a decision inside one step, but the overall workflow isn't necessarily deciding what to do next.

That's AI-powered automation.

Now consider:

Goal ↓ Reason ↓ Choose Action ↓ Use Tool ↓ Observe Result ↓ Re-evaluate ↓ Choose Next Action ↓ Repeat / Stop

The system's next action depends on what it observes.

That's where things start becoming agentic.

The important question: Who decides what happens next?

This is probably the simplest way to distinguish the two.

Imagine an incident-management system.

Traditional workflow Incident detected ↓ Classify incident ↓ Create ticket ↓ Notify engineer ↓ End

The sequence is known beforehand.

Now consider an agent:

Incident detected ↓ Investigate ↓ Check logs ↓ Observe unusual errors ↓ Check recent deployments ↓ Find suspicious deployment ↓ Evaluate possible remediation ↓ Request approval ↓ Execute remediation ↓ Verify recovery

The important part isn't simply that an LLM is involved.

The important part is that the system determines its next action based on what it discovers.

Five systems that are often confused with agents System What it does Typical decision-making LLM application Generates responses User/developer RAG application Retrieves context + generates Mostly predefined AI workflow Executes a sequence Developer AI copilot Assists a human Human AI agent Pursues a goal through actions System + policies

These categories aren't absolute.

A real product can combine several of them.

But the distinction helps when designing the architecture.

Tool calling isn't enough

Tool use is important for agents, but using a tool doesn't automatically create agency.

For example:

Question ↓ LLM ↓ Weather API ↓ Answer

The model used a tool.

That doesn't necessarily make the application an agent.

Compare it with:

Goal ↓ Search customer ↓ Review previous conversations ↓ Check open tickets ↓ Identify unresolved issue ↓ Search documentation ↓ Find missing information ↓ Search another source ↓ Prepare customer briefing

Here, the system's actions depend on intermediate results.

That's much closer to agentic behavior.

Planning isn't enough either

Some systems are called agents simply because an LLM generates a plan.

For example:

1. Search database

2. Analyze results

3. Send email

But what happens if step 1 fails?

If the system simply executes the predetermined sequence, it isn't necessarily very agentic.

A more adaptive system might do this:

Goal ↓ Create plan ↓ Execute ↓ Observe result ↓ Plan no longer works ↓ Generate alternative ↓ Execute alternative ↓ Evaluate

The key capability isn't just planning.

It's replanning based on observations.

Observation is a critical capability

A useful mental model for agentic systems is:

Reason → Act → Observe → Adapt

rather than:

Prompt → Generate → Finish

Suppose you tell an agent:

"Find the cause of this production error."

It could:

Inspect logs. Find an unusual error. Check recent deployments. Identify a possible correlation. Investigate the deployment. Discover that the hypothesis doesn't explain the problem. Change direction. Investigate another possibility. Produce a conclusion.

The agent's behavior changes because the environment gives it new information.

That feedback loop is one of the most important characteristics of an agent.

Does memory make something an agent?

Not necessarily.

Memory is useful, but it isn't the defining characteristic.

A customer-support application can remember:

previous conversations customer preferences account information past interactions

But if it still follows a fixed workflow, memory alone doesn't make it an agent.

Memory is a capability.

Agency is about decision-making and action.

Agents still need boundaries

There's another important misconception:

More autonomy = better agent.

In production, unlimited autonomy can actually create significant risks.

Imagine giving an agent access to:

production databases payment systems customer information cloud infrastructure deployment pipelines email

The system may be capable of taking actions, but that doesn't mean every action should be permitted.

A safer architecture looks more like:

Goal ↓ LLM Reasoning ↓ Policy Check ↓ Permission Check ↓ Tool Execution ↓ Observe Result ↓ Next Decision

Some actions can be automatic.

Some can require human approval.

Others should be blocked completely.

That's where agentic AI becomes an engineering problem, not just an LLM problem.

Probabilistic reasoning, deterministic execution

One architectural principle I find particularly useful is separating reasoning from execution.

LLMs are probabilistic.

Production systems often need predictable behavior.

So instead of allowing the model to directly control everything, you can separate:

┌──────────────────────┐ │ Goal / Context │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ LLM Reasoning │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ Policy & Validation │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ Execution Layer │ └──────────┬───────────┘ ↓ ┌──────────────────────┐ │ External Systems │ └──────────┬───────────┘ ↓ Observation │ └──────→ Next Decision

The model can determine what it thinks should happen.

The execution layer determines what is actually allowed to happen.

That distinction becomes increasingly important as agents interact with real systems.

So, what makes something an agent?

There's no single universally accepted definition.

But I'd look for these capabilities:

1. Goal-directed behavior

The system is working toward an outcome rather than simply generating text.

1. Action selection

It can choose between possible actions.

1. Tool use

It can interact with external systems.

1. Observation

It can see the result of its actions.

1. Adaptation

It can change its approach based on what it observes.

1. State

It can maintain enough context to pursue its goal across multiple steps.

1. Bounded autonomy

Its actions are constrained by permissions, policies, budgets, and other controls.

The more of these capabilities a system has, the stronger the case for calling it an AI agent.

Here's a practical test

Instead of asking:

"Does this application use an LLM?"

ask:

"What happens when the expected path breaks?"

If the answer is:

"The workflow follows the next predefined step."

You're probably looking at automation.

If the answer is:

"The system evaluates the result, considers alternatives, and determines what to do next within its permitted boundaries."

You're much closer to an agent.

Do we actually need an agent?

This might be the most overlooked question.

Not every problem requires an agent.

If a process is:

predictable deterministic well-defined easy to express as a sequence

then a traditional workflow may be the better architecture.

Agents become more interesting when:

the environment is dynamic the path isn't known beforehand multiple actions are possible results influence future decisions the system needs to recover from unexpected outcomes

The goal shouldn't be to make everything agentic.

The goal should be to use the right architecture for the problem.

How we're thinking about it at Nuroen

At Nuroen, we're interested in the engineering layer between AI reasoning and real-world execution.

The challenge isn't simply putting an LLM inside a workflow and calling it an agent.

It's building systems where agents can reason and act while the surrounding execution environment provides meaningful controls.

That means considering:

Tool permissions Policy enforcement Human-in-the-loop actions Execution limits Observability Auditability Controlled autonomy

In short:

Let the model reason. Let the system govern execution.

That's a more useful foundation for production agentic systems than simply adding the word agent to an AI workflow.

The bigger question

The AI industry probably isn't going to stop using the word agent.

And that's fine.

But as engineers, we can still be precise.

Instead of asking:

"Is this an AI agent?"

ask:

What decisions can it make? What actions can it take? What can it observe? Can it change its plan? What happens when something fails? What prevents unsafe actions? Who controls its permissions?

Those questions tell us far more about a system than the label agent.

Final thought

Not every AI-powered workflow needs to be an agent.

And not every agent needs unlimited autonomy.

Sometimes a deterministic workflow with an LLM handling one difficult step is exactly the right solution.

Other problems genuinely require a system that can:

Reason → Act → Observe → Adapt.

The important thing is to design for the problem—not the buzzword.

What do you think is the minimum capability an AI system needs before you'd call it an agent?

Hashnode SEO setup

Title: Should Every AI-Powered Workflow Be Called an Agent?

Subtitle: Not every AI workflow is an agent. Here's how reasoning, tool use, observation, adaptation, and bounded autonomy separate agents from automation.

Slug: should-every-ai-powered-workflow-be-called-an-agent

Tags: AI · AI Agents · Agentic AI · LLM · Software Engineering

Canonical URL: If this article is also published on Nuroen's website, set the Nuroen website article as the canonical URL in Hashnode rather than creating competing SEO versions.

Suggested cover text:

Should Every AI-Powered Workflow Be Called an Agent?

with a visual showing:

WORKFLOW → AGENT

and underneath:

Follow → Decide → Act → Observe → Adapt

We see AI-powered workflows handling customer support, document processing, lead qualification, incident management, reporting, and dozens of other repetitive tasks.

But as AI agents become more capable, a different approach is emerging:

Agentic automation.

The terms are often used interchangeably, but there is an important difference in how these systems execute work.

AI Automation: Smarter Workflows

Traditional automation works around predefined rules:

Trigger ↓ Step 1 ↓ Step 2 ↓ Step 3 ↓ Output

Adding AI can make individual steps much smarter.

For example, a support workflow could:

Receive a customer request Use an LLM to understand the request Classify the issue Route it to the appropriate team Generate a response

The workflow is still largely predetermined.

The AI improves the individual tasks, while the workflow determines the overall path.

A simple way to describe this is:

“Here is the workflow. Make each step smarter.”

Agentic Automation: Start With the Goal

Agentic automation approaches the problem differently.

Instead of defining every step in advance, we provide an objective and allow an agent to determine how to accomplish it within defined boundaries.

Consider an IT operations example:

“Investigate this production incident and determine the next action.”

An agent could:

Understand the goal ↓ Gather context ↓ Check monitoring data ↓ Inspect relevant systems ↓ Reason about possible causes ↓ Choose an action ↓ Execute / request approval ↓ Verify the result

The important difference is that the agent isn't necessarily following one fixed path.

The path can change based on what it discovers.

The Core Difference

A useful mental model is:

AI Automation

Input → AI → predefined task → Output

Agentic Automation

Goal → Context → Plan → Tools → Action → Verification

AI automation asks:

How can we make this workflow smarter?

Agentic automation asks:

What actions are required to achieve this outcome?

That distinction becomes important as workflows become more complex.

Why Adaptability Matters

Real-world systems don't always behave according to the original workflow.

An API might fail.

Data might be incomplete.

A required system might be unavailable.

A condition might change halfway through execution.

A predefined workflow may not have a branch for every possible scenario.

Agentic systems can potentially respond to these situations by reassessing the context and choosing another available action.

For example:

Check database ↓ Data unavailable ↓ Agent reassesses ↓ Check backup source ↓ Gather required information ↓ Continue workflow

This is where agentic automation can be useful for workflows that contain significant variability.

But More Autonomy Requires More Control

This is probably the most important consideration for enterprise AI.

Giving an agent the ability to reason and act isn't enough.

The system also needs boundaries.

1. Human-in-the-loop

Certain actions may require explicit approval.

For example:

Read customer information ↓ Analyze issue ↓ Prepare account change ↓ Human approval ↓ Execute change

The agent can prepare the action without automatically committing it.

1. Governance

Organizations need policies defining what an agent can access and what actions it can perform.

For example:

Which systems can it access? Which tools can it use? Which operations are read-only? Which actions require approval? What data can it access?

Autonomy without boundaries can create a very different risk profile from conventional automation.

1. Observability

When an agent makes multiple decisions and tool calls, teams need visibility into what happened.

A useful execution record might show:

Goal ↓ Reasoning / decision ↓ Tool selected ↓ Tool input ↓ Tool result ↓ Next decision ↓ Final outcome

This makes it easier to understand and audit an agent's execution.

1. Verification

An agent shouldn't simply assume that an action succeeded.

For important workflows, it should be possible to verify the outcome.

For example:

Create incident ↓ Check incident status ↓ Confirm assignment ↓ Verify notification ↓ Complete

Execution and verification are two different things.

Does Agentic Automation Replace Traditional Automation?

Not necessarily.

Deterministic automation remains useful when the process is predictable.

If you know exactly what should happen:

When invoice arrives ↓ Extract data ↓ Validate fields ↓ Store record

there may be little reason to introduce additional autonomy.

The more useful question is:

Where does the workflow require reasoning, adaptation, or decision-making?

Those are the areas where an agentic approach may provide value.

A Simple Framework

You can think about the evolution like this:

Traditional Automation ↓ Follow predefined rules ↓ AI Automation ↓ Make predefined tasks smarter ↓ Agentic Automation ↓ Work toward goals within defined boundaries

The progression isn't necessarily about replacing one technology with another.

It's about matching the execution model to the complexity of the problem.

The Enterprise Architecture Gets Bigger

A production-grade agentic system isn't just an LLM.

A practical architecture can involve:

          ┌──────────────┐
          │     Goal     │
          └──────┬───────┘
                 ↓
          ┌──────────────┐
          │    Agent     │
          └──────┬───────┘
                 ↓
    ┌────────────┼────────────┐
    ↓            ↓            ↓
  Tools         Data       Knowledge
    │            │            │
    └────────────┼────────────┘
                 ↓
            Execution
                 ↓
          Verification
                 ↓
          Governance
                 ↓
          Human Control

This is why building enterprise agents is fundamentally different from simply adding an LLM to an existing workflow.

The model is only one component.

The surrounding system determines how safely and reliably that intelligence can operate.

From Tasks to Outcomes

The biggest conceptual shift is this:

AI automation focuses on tasks.

Agentic automation focuses on outcomes.

That doesn't mean every workflow needs an autonomous agent.

It means we now have another execution model for problems where fixed workflows aren't enough.

The challenge ahead isn't simply making agents more autonomous.

It's making them useful, observable, governed, and reliable enough to operate inside real systems.

That's where the interesting engineering work begins.

What are you seeing in your own projects?

Are you extending traditional automation with AI, or moving toward goal-oriented agentic workflows?

#AI #AIAgents #AgenticAI #Automation #GenerativeAI #LLM #EnterpriseAI #MCP #SoftwareEngineering #DevTools

The word “agent” has become one of the most overloaded terms in AI.

Add an LLM to a workflow.

Give it a few tools.

Let it call an API.

Add some memory.

Suddenly, the system is marketed as an AI agent.

But is it actually an agent?

Or did we just give a workflow a better name?

This distinction matters because the architecture, reliability, observability, testing, and security requirements change significantly once a system is allowed to make decisions and take actions dynamically.

The simplest workflow isn't an agent

Consider a typical automation:

Trigger
   ↓
Fetch customer
   ↓
Check account
   ↓
Create ticket
   ↓
Send email
   ↓
Done

This is a workflow.

Every step is known beforehand.

The system doesn't need to decide what happens next. It simply executes the path that a developer designed.

That's not necessarily a bad thing.

In fact, deterministic workflows are often better for processes that are predictable.

For example:

def process_order(order):
    validate_order(order)
    charge_payment(order)
    create_shipment(order)
    send_confirmation(order)

There is no reason to introduce autonomous reasoning here.

The developer already knows the correct sequence.

Then we add an LLM

Now imagine this:

User Request
     ↓
     LLM
     ↓
Tool Selection
     ↓
API Call
     ↓
Response

The model can decide which tool to call.

For example:

{
  "tool": "get_customer",
  "arguments": {
    "customer_id": "12345"
  }
}

The application executes the function and sends the result back to the model.

This is tool calling.

And tool calling is extremely useful.

But tool calling alone doesn't automatically create an agent.

Tools are the hands, not the brain

A useful mental model is:

              AGENT
      ┌─────────────────────┐
      │ Goals               │
      │ Reasoning           │
      │ Planning            │
      │ Memory / State      │
      │ Policies            │
      │ Decision Making     │
      └──────────┬──────────┘
                 │
          Orchestration
                 │
          Tool Calling
                 │
       ┌─────────┼─────────┐
       ↓         ↓         ↓
     APIs      Search     Code

Tools give a system the ability to act.

But an agent needs to determine:

• What is the goal?

• What should happen next?

• Which tool should be used?

• Do I have enough information?

• Did the previous action succeed?

• Should I try another approach?

• Should I stop?

• Should I ask a human?

That's where things become genuinely agentic.

Workflow vs AI-powered workflow vs agent

The distinction becomes clearer if we put the three side by side.

A workflow might say:

"After step 2, always execute step 3."

An agent might say:

"Given the current state and objective, step 3 is the best action."

That difference is subtle—but architecturally important.

What makes something agentic?

There isn't one universally accepted definition of an AI agent.

But a useful engineering definition is:

An agent is a system that pursues a goal by observing its environment, reasoning about possible actions, selecting actions, executing them through available capabilities, and adapting based on the resulting state.

That gives us several important components.

1. A goal

An agent needs an objective.

For example:

"Investigate this production incident and determine
the safest next action."

That's different from:

"Run these five functions."

The first describes an outcome.

The second describes an execution path.

2. State and context

The system needs to understand what has already happened.

For example:

Incident detected
      ↓
Logs inspected
      ↓
Database checked
      ↓
Possible root cause identified
      ↓
Next action?

Without state, the system has difficulty reasoning about the current situation.

State doesn't necessarily mean long-term memory.

It can simply be the current execution context.

3. Reasoning and planning

An agent needs some mechanism for determining what to do next.

A simplified loop could look like:

while not goal_complete:

    state = observe()

    plan = reason(
        goal=goal,
        state=state,
        available_tools=tools
    )

    action = select_action(plan)

    result = execute(action)

    state = update_state(result)

The important part isn't that an LLM is present.

The important part is the decision loop.

4. Tool selection

A real agent shouldn't necessarily call every available tool.

Suppose an IT operations agent has:

get_logs()
get_metrics()
search_runbook()
restart_service()
create_incident()
notify_engineer()

If a service is experiencing latency, the agent might reason:

1. Check metrics
2. Inspect logs
3. Search relevant runbook
4. Determine probable cause
5. Recommend remediation

It shouldn't automatically jump to:

restart_service()

Tool access without decision boundaries can create a dangerous system.

5. Feedback

This is another major difference.

A simple workflow:

Action → Next Step

An agent:

Action
  ↓
Observe Result
  ↓
Evaluate
  ↓
Decide
  ↓
Next Action

For example:

Search logs
     ↓
No useful evidence
     ↓
Try metrics
     ↓
Anomaly detected
     ↓
Inspect deployment
     ↓
Possible bad release

The path isn't necessarily known ahead of time.

That's where agentic behavior starts becoming useful.

6. Knowing when to stop

This is an underrated part of agent design.

A poorly designed agent can keep acting simply because it has tools available.

A production agent needs termination conditions.

For example:

IF confidence >= threshold
    → provide recommendation

IF action requires approval
    → pause

IF risk > allowed threshold
    → escalate

IF goal achieved
    → stop

IF repeated failure
    → terminate and escalate

An agent isn't more useful because it can keep going forever.

A trustworthy agent knows when not to act.

And this is where governance becomes important

Giving an AI system tools is easy.

Giving it unrestricted access to those tools is another matter.

Imagine an agent with access to:

CRM
Database
Production Infrastructure
Payments
Email
Customer Records

Now ask:

What happens if the model makes the wrong decision?

The architecture needs more than tool calling.

You need controls such as:

                AGENT
                  ↓
             POLICY CHECK
                  ↓
          ┌───────┴───────┐
          ↓               ↓
      Low Risk         High Risk
          ↓               ↓
       Execute          Approval
                          ↓
                        Human

This is particularly important when agents can modify real-world state.

Not everything should be autonomous

This is probably the most important point.

There is a tendency in AI development to treat autonomy as automatically better.

It isn't.

Consider these two operations:

Operation A

Read product documentation
→ answer user question

High autonomy is relatively reasonable.

Operation B

Transfer $50,000
→ update financial records
→ notify customer

You probably don't want an LLM deciding everything independently.

A better architecture might be:

Agent
  ↓
Analyze
  ↓
Prepare Action
  ↓
Policy Check
  ↓
Human Approval
  ↓
Execute

The goal isn't maximum autonomy.

The goal is appropriate autonomy.

A better architecture for production agents

A practical agent architecture might look like this:

                 ┌──────────────┐
                 │     Goal     │
                 └──────┬───────┘
                        ↓
                ┌───────────────┐
                │   Reasoning   │
                └───────┬───────┘
                        ↓
                ┌───────────────┐
                │ Orchestration │
                └───────┬───────┘
                        ↓
                 ┌─────────────┐
                 │ Policy Check│
                 └──────┬──────┘
                        ↓
                ┌───────────────┐
                │  Tool Calling │
                └───────┬───────┘
                        ↓
              ┌─────────┼─────────┐
              ↓         ↓         ↓
            APIs      Search     Code
              │         │         │
              └─────────┼─────────┘
                        ↓
                     Result
                        ↓
                   Evaluation
                        ↓
                  Next Decision

This architecture makes something important explicit:

Tool calling is part of the agent—not the definition of the agent.

So where should we draw the line?

Here's a simple test I like:

Ask:

Can the system decide what to do next based on the goal and current state?

If the answer is no, you're probably looking at a workflow.

If the answer is sometimes, you may have an LLM-powered workflow.

If the answer is yes, and the system can dynamically choose actions, observe results, adapt, and operate within defined boundaries, you're much closer to an agent.

But there's another question: Should it be an agent?

This is where engineering judgment matters.

Don't turn a deterministic workflow into an autonomous agent just because the word “agent” is fashionable.

If you already know the correct path:

A → B → C → D

a workflow may be the right architecture.

If the environment is uncertain:

Goal
 ↓
Observe
 ↓
Decide
 ↓
Act
 ↓
Observe
 ↓
Decide
 ↓
...

then an agent can provide real value.

The architecture should follow the problem—not the marketing terminology.

The real challenge isn't building agents

Building something that looks like an agent is becoming increasingly easy.

Frameworks make tool calling easier.

Models are becoming better at reasoning.

APIs are becoming easier to connect.

Agent builders can generate workflows from natural language.

The harder problem is making these systems reliable enough to operate in the real world.

That means answering questions like:

• Can we explain why an action happened?

• Can we reproduce an execution?

• Can we restrict what an agent can access?

• Can we control autonomy?

• Can we enforce approval gates?

• Can we set budget limits?

• Can we stop an agent?

• Can we audit its actions?

• Can we validate behavior before deployment?

Those are engineering problems—not prompt-writing problems.

The future may not be “everything is an agent”

I think we're going to see a more nuanced architecture.

Something like:

                Enterprise System
                       │
             ┌─────────┴─────────┐
             │                   │
        Deterministic        Agentic
        Workflows            Systems
             │                   │
       Known paths          Uncertain paths
       Fixed logic          Dynamic decisions
       Predictable          Adaptive
             │                   │
             └─────────┬─────────┘
                       ↓
                  Governance
                       ↓
                    Runtime

The strongest systems may combine both.

Use deterministic workflows where certainty is valuable.

Use agents where reasoning and adaptation create value.

And put governance around both.

Final thought

Maybe the better question isn't:

“Is this an agent?”

It's:

“What decisions is this system allowed to make?”

Because that's ultimately what separates a useful AI system from a risky one.

Tool calling gives AI hands.

Reasoning gives it the ability to choose.

State gives it context.

Orchestration gives it coordination.

Governance gives it boundaries.

And together, those are much closer to what we should actually mean when we say AI agent.

What do you think?

Where would you draw the line between:

Workflow → AI Workflow → Agent?

Is tool calling enough?

Or does an agent fundamentally need the ability to decide what happens next?

Suggested Hashnode tags: AI · AI Agents · Agentic AI · LLM · Software Architecture

Suggested cover headline:

WORKFLOW OR AGENT? Where does agentic behavior actually begin?

Use the technical diagram you created earlier as the cover rather than a Nuroen product screenshot. It will make the article feel like a developer architecture discussion first, with Nuroen as the company behind the perspective rather than an advertisement.