The use case is the boundary that transforms human intention into a distributed AI architecture.

Contents

• The AI-Native question
• Ivar Jacobson and Ericsson
• AXE, PLEX and Function Blocks
• HLPLEX, processes and FORLOPP
• From function blocks to AI building blocks
• One use case, decomposed end to end
• The use case as an AI boundary
• Conclusion

The AI-Native question

The AI industry often presents intention-driven systems as something entirely new. But an AI-Native system does not simply receive an intention and autonomously invent the entire solution.

It must understand what the intention means, determine what the system is responsible for, identify the participating actors, decompose the business process and select the appropriate capabilities.

The real starting point is not the agent.

It is the use case.

Actor
  → Intent
    → Use Case
      → Business Process
        → Responsibilities
          → AI Building Blocks
            → Outcome

The use case turns an intention into a bounded responsibility. It tells the system who participates, what must happen, what is allowed, what is outside the boundary, what counts as success and what evidence must be produced.

A requirement states what should happen. A use case defines the bounded process through which it can happen.

Ivar Jacobson and Ericsson

Before use cases became widely associated with UML, Objectory and the Rational Unified Process, Ivar Jacobson was working at Ericsson on large, real-time telecom systems such as AKE and AXE, including PLEX.

Jacobson is widely credited with introducing use cases in 1986 as a way to specify functional software requirements. The idea emerged from a practical problem: how to understand systems whose behaviour was distributed across software units, processes, signals and hardware.

The historical connection matters because the use case was not created as a decorative documentation technique. It was a way to reason about responsibility:

Who interacts with the system?
What does the actor need to accomplish?
What functions are required?
Where does each responsibility live?
How do the units cooperate?

AXE, PLEX and Function Blocks

The AXE system gives this history a concrete form. PLEX-C was used to produce software for the central processor of the AXE control system. Functional blocks could also involve hardware and regional software running in regional processors.

This meant that a system function was not necessarily located in one place:

Central Software
  + Regional Software
    + Hardware
      + Functional Blocks
        + Signals

The conceptual decomposition was:

Actor
  → Use Case
    → System Function
      → Function Block
        → Software Unit
          → Process
            → Signal / Event

A Function Block was not simply a source-code file. It represented a function within a larger application system, potentially combining software, local data, signal interfaces, associated hardware and regional software.

**Legend**: the use case gives the function its purpose; a Function Block realizes it; a signal connects it to another block as a message.

The use case gave the function its reason for existing. The Function Block gave the function an architectural home.

HLPLEX, processes and FORLOPP

HLPLEX made active execution and concurrency more explicit. Modules could contain processes; processes could execute concurrently, have multiple instances and communicate through event paths.

Function Block
  └── Module
       ├── Process A
       ├── Process B
       └── Process C

Process A
  → Event
    → Process B

The unit was no longer only a container of functionality. It became an active participant in a larger process.

The AXE documentation also describes FORLOPP as a sequence of events. When multiple Function Blocks participated in the same call, records could be linked into a chain with a Forlopp Identity, or FID.

Call
  → Record in Block A
    → Record in Block B
      → Record in Block C
        → Record in Block D

FID = identity of the distributed call

The FID allowed the system to identify and release a specific call in the event of a software failure. This is not identical to a modern trace ID or agent run ID, but the architectural question is related:

How does one preserve the identity of an operation while it crosses multiple units?

From function blocks to AI building blocks

The history of software paradigms is also a history of changing answers to one question:

What is the right unit for realizing a responsibility?

OOP
  → Object = data + behaviour

PLEX
  → Function Block = function + software + hardware

HLPLEX
  → Process = state + behaviour + events

Erlang / Elixir
  → Process = isolation + messages + supervision

Ruby / Ractors
  → Unit = isolation + parallel execution

AI-Native
  → Agent = state + behaviour + intent + feedback

The paradigms are not identical and do not form a simple chain of direct inheritance. They respond to related pressures: decomposition, encapsulation, communication, concurrency, recovery, composition and responsibility.

An AI-Native system is not composed only of agents. It is composed of different building blocks, each with a distinct role:

Responsibility	Building block
Specialized knowledge	Skill / RAG
Concrete execution	Tool
External integration	MCP
Known sequence	Workflow
Adaptive judgment	Agent
Persistent context	Memory
Lifecycle control	Hook
Sensitive authorization	Human actor

The use case determines which of these are necessary.

One use case, decomposed end to end

Consider this intention:

Investigate a production incident and produce a verified report.

This is not yet an architecture. We first turn it into a bounded use case:

An authorized engineer requests an investigation. The system gathers relevant documentation and telemetry, forms and tests hypotheses, records evidence, produces a report and requests human approval before any risky production change.

The distributed business process becomes visible:

Incident Investigation
  ├── receive the request
  ├── identify the affected service
  ├── retrieve relevant documentation
  ├── inspect logs and metrics
  ├── form hypotheses
  ├── run safe verification steps
  ├── evaluate evidence
  ├── produce a report
  └── request approval for risky action

Each responsibility can now be assigned to an appropriate participant:

Receive and classify request       → Coordinator Agent
Retrieve runbooks and documentation → RAG
Apply incident procedure           → Skill
Query logs and metrics             → Tool
Connect to observability systems   → MCP
Compare hypotheses                 → Investigation Agent
Execute standard checks            → Workflow
Preserve findings and context      → Memory
Block unsafe operations            → Hook / Policy
Approve production changes         → Human Actor

**Legend:** the diagram separates context, execution and governance; the use case routes the intention through bounded capabilities toward evidence and human-verified completion.

The diagram does not show one super-agent performing everything. It shows a distributed process in which each building block has a bounded responsibility.

The use case as an AI boundary

The use case is the boundary that transforms intention into AI architecture:

Use Case
  → defines purpose
    → assigns responsibility
      → restricts authority
        → selects building blocks
          → defines completion

For every agent, skill, tool or workflow, we should be able to ask:

Which use case requires this?
Which responsibility does it realize?
What authority does it have?
What does it communicate?
What evidence does it produce?
When must it stop?

This prevents common category errors:

Agent ≠ Skill
Skill ≠ Tool
Tool ≠ MCP
MCP ≠ RAG
RAG ≠ Memory
Hook ≠ Workflow

Not every responsibility needs to become an agent. Not every capability needs autonomy. Not every document needs to become memory. Not every integration needs to become an MCP server.

The use case must decide.

Conclusion

The history of software composition can be read as a history of changing units:

Object
  → Function Block
    → Process
      → Supervised Application
        → Ractor
          → Agent

Each unit addressed a different aspect of complexity:

Object           → encapsulation
Function Block   → functional composition
Process          → active execution
Message          → communication
Supervision      → recovery
Ractor           → isolation and parallelism
Agent            → intention and adaptive action

But the unit alone is never enough. A system also needs purpose, responsibility, authority, context, constraints, evidence and completion.

The use case provides that definition. It is where a human intention becomes a system responsibility, where a business process becomes an architectural boundary and where the system decides what belongs inside the solution and what must remain outside it.

AI-Native systems do not begin with agents. They begin with intentions that become use cases, use cases that become responsibilities, and responsibilities that become carefully chosen building blocks.

The use case is where intention becomes architecture.

References

• Ivar Jacobson — biography and work
• Ivar Jacobson International
• Object Management Group — UML
• Ruby Ractor documentation
• Model Context Protocol
• Google Cloud — Agentic AI security operations workflow

The AXE, PLEX and HLPLEX historical details in this article were checked against Ericsson training manuals supplied as research material. The article paraphrases those materials and does not reproduce their proprietary diagrams or code.