Understanding the work

What are agents, agentic workflows and software factories?

An agent carries out a task. An agentic workflow connects work across steps. A software factory repeats how software is built and checked.

Use them to change real work: test a website, produce a checked software change or prepare an invoice. Your enterprise's systems, data and rules determine how they should work.

What does each one do?

What is an AI agent?

An AI agent uses a model, instructions and tools to carry out an assigned task. It chooses an allowed action, inspects the result and continues or asks for help. For example, it can look up an order and prepare invoice lines. You decide its access and when it must stop. A chat interface alone does not make a system an agent.

What is an agentic workflow?

An agentic workflow connects steps in a business process, using agents where flexible action helps. Other steps can remain ordinary software, fixed rules or human decisions. Invoice preparation, checks and approval form one connected workflow. It may use just one agent. Shared records and clear handoffs keep the case moving.

What is a software factory?

Here, a software factory is a repeatable process for a defined kind of software output, such as changes to an employee portal. It accepts a request, builds a candidate, checks it and packages the result for review. Agents can perform parts of the process. Versioned inputs, independent checks and a release owner make the result traceable.

The term has different uses; we mean software delivery here. A finance workflow runs business work. The software that implements it can be a factory's output.

For agents and workflows, the architectural guidance from Anthropic and Microsoft favors the simplest design that meets the work, adding coordination only when it helps.

Illustrative engineering example

Test a website, then make software delivery repeatable.

A website-testing agent can follow an agreed user journey in a test environment, gather screenshots and report a failure. The team defines allowed sites, test accounts and actions. Authoritative assertions check the expected behavior; the agent's summary alone is insufficient.

A software factory might use that agent as one part of a process for repeated internal-portal changes:

1.Accept the request
The business owner agrees the requirement, affected users and acceptance cases. Missing rules return for clarification.
2.Build a candidate
The engineering team configures agents and ordinary build tools to prepare a patch in an isolated workspace against a recorded code version.
3.Check and repair
Protected acceptance checks run against the built application. Failures return with evidence for bounded repair or human intervention.
4.Hand over for release
The reviewer receives the exact change, results and known gaps. An authorized owner decides whether to merge and release.

The repeatable output is a reviewable software change with evidence. A factory still needs engineering judgment, maintenance and production release controls.

Build a website-testing agent Design a software factory

Other technical work your team can build towards.

Forward Deployed Engineering (FDE): Turn a customer problem into a bounded solution: practise stakeholder discovery, build against the customer's requirements, demonstrate the result and explain the operating handoff.
Model fine-tuning: Adapt a model for a defined task using suitable training examples. Compare it with the baseline on separate evaluation data. For a different starting point, explore model development.
Authorized website security testing: Build agent-assisted checks for an approved target, access and test boundary. Verify findings and false alarms, then review remediation with the security owner. A completed test cannot establish that a site is secure.

Illustrative finance example

Prepare a customer invoice.

A finance team wants to prepare invoices from approved service orders. Here is an illustrative design.

The agent prepares a draft.

It reads the permitted order records, checks related documents when a description is unclear, and prepares draft invoice lines with their source references. A missing order approval goes back to a person. The agent has no permission to issue the invoice.

The workflow carries the case through.

Software checks customer identity, prices, totals and duplicates against authoritative records. Finance reviews exceptions and approves issue. The billing system records the approved invoice. The workflow tracks which step succeeded, so a retry does not create a second invoice.

The owner checks the complete result.

Does the draft match the approved order? Can a user see why a line was included? Do missing approvals stop issue? Do repeated requests preserve one invoice? The finance owner agrees these checks before the team builds.

The intended improvement is less manual preparation with correct billing and clear exceptions. Measure preparation time, correction work and approval delays against your own baseline.

Design the invoice workflow Build an agentic workflow

Where environments, simulations and evaluations fit.

Your team needs somewhere to build and test the work, realistic cases to try, and checks that show what happened.

Business environment: the working context: A bounded setup with the systems or interfaces, representative data, rules, permissions and roles needed for the agreed work. An invoice project needs consistent order and billing records. A software project needs a repository, dependencies, test accounts and a running application.
Simulation: the situation to work through: Run a realistic case inside that environment. Include an ordinary request and exceptions, such as a missing approval, a duplicate request or a failing dependency. People practise their decisions and handoffs; agents attempt their assigned steps.
Evaluation: the evidence against agreed checks: Inspect what actually happened and compare the outputs with expected results. Assess a person's responsibilities separately from an agent's performance. The operating owner decides whether the complete workflow meets its acceptance criteria.

Results cover the conditions tested. Production access, security, capacity, monitoring and support still need their own decisions.

Explore simulations and business environments

Build around your enterprise's work.

Bring one workflow or recurring software-delivery problem. Your operating experts explain its records, decisions and exceptions. IT and security owners identify approved tools and access. Your team builds and tests, with Nuvepro shaping simulations, the business environment and preparation around your enterprise.

Reuse suitable AI platforms, models and automation you already have. Identify the interfaces that need development or simulation and who will own them.

Define the outputs before starting: what the team will build, the cases it must handle, evidence to collect and the handoff. Include production integration, release or continuing support explicitly if you need them.

Discuss your enterprise project

Sources and further reading.

Anthropic: Building effective agents
Distinguishes predefined workflows from model-directed action and discusses when simpler approaches are enough.
Microsoft: AI agent orchestration patterns
Compares direct model calls, single agents and multi-agent systems, including coordination costs.
GitHub: About protected branches
Documents configurable review and required-check controls relevant to software delivery. These must be set up and tested.

The examples and enterprise project design above are Nuvepro's explanations. References do not establish an available integration, partnership or completed implementation.