PaperlayerView exact revision on arXiv

Source-linked AI summary

Forms of LLM-Integrated Applications from LLM-Chats to Autonomous AI Agent System

Irene Weber

arXiv:2610.11899v1cs.CLcs.AIcs.SE

TL;DR

Widely used labels for LLM-integrated systems lack a systematic account of how systems are built and how forms relate. This paper describes established forms in a common vocabulary and illustrates the descriptions with 22 systems, fully covering six forms and treating a seventh in part.

  • Problem

    Widely used labels for LLM-integrated systems lack a systematic account of how the systems are built and how one form compares architecturally with another.

    Source: §I · p. 1

  • Method

    The paper describes established forms in a common vocabulary and records their architecture, user intervention, agent calls per task, and available tools.

    Source: §I · p. 1, H. Summary of Selected Systems · p. 6

  • Results

    The paper describes six forms in full and a seventh in part, illustrating them with a survey of 22 systems.

    Source: §VI · p. 7

  • Takeaways & Limitations

    The classification offers a shared basis for making the field more accessible, comparing technologies, and using emerging terminology in research.

    Source: §VI · p. 7

    The corpus is illustrative rather than representative, so it supports no frequency claims; commercial-system descriptions may disclose limited technical detail.

    Source: D. Limitations and Future Work · pp. 6–7

Abstract

from arXiv · show

Large language models (LLMs) are increasingly embedded as components in software systems, marketed under labels such as chatbot, copilot, retrieval-augmented generation, workflow, coding agent and AI agent. Whether these labels denote genuine architectural forms or serve as branding has not been assessed systematically. In the sources surveyed, labels do carry architectural content, most clearly in vendor usage: copilot denotes a router-worker architecture operating a host application under step-by-step user confirmation, while the more recent shift to the label agent coincides with AI-planned multi-step execution of which the user sees only the outcome. The coding agents of four major providers share one architecture, a reason-and-act loop delegating to subagents. This survey describes seven recurring forms---LLM chats, custom agents, retrieval-augmented generation (RAG), AI-enhanced workflows, copilots, coding agents, and, in part, agentic RAG---in a common vocabulary of agents and tools. Each is characterized along four structural dimensions (agentic RAG only partially): the architectural pattern, the control of execution and the point of user intervention, the number of agent calls per task, and tool use. An illustrative corpus of 22 systems from research publications and vendor documentation grounds the descriptions and shows where they reach their limit.

I. INTRODUCTION

Labels for LLM-integrated applications are widely used, but whether they denote distinct architectural forms remains unclear. The paper offers a common vocabulary for describing seven established forms and illustrates its limits with 22 systems.

I. INTRODUCTION

  • LLMs embedded in software systems can select actions, parameterize external services, and influence subsequent system behavior.Source: §I · p. 1
  • The architectural meaning of labels remains unclear, making the field difficult to survey and research approaches difficult to position and compare.Source: §I · p. 1
  • The paper introduces concepts for describing LLM-integrated applications at the level of whole-system architectures.These include AI agent, tool, monofunctional and multifunctional agent, and recurring architectural patterns.Source: §I · p. 1
  • Seven established forms are characterized using four dimensions: architecture, user control and intervention, agent calls per task, and tool use.Source: §I · p. 1
  • An overview of 22 systems illustrates the descriptions and their limits; the paper reports that copilot denotes one architecture while the shift to agent marks an architectural shift.Source: §I · p. 1

II. RELATED WORK

Related work covers architectural patterns, multi-agent systems, and taxonomies, but the cited work does not systematically characterize applications across established forms. The following section introduces the terminology used to describe systems assembled from smaller units.

II. RELATED WORK

  • Prior surveys address multi-agent collaboration, application domains, or the distinction between AI agents and agentic AI, while cited classifications draw examples from research prototypes.Source: §II · p. 2
  • An earlier taxonomy classified individual LLM components but did not describe whole-system architectures.Source: §II · p. 2
  • The closest cited taxonomy focuses on autonomous LLM-powered multi-agent systems and seven open-source projects, whereas this paper describes a broader range of forms in uniform terms.Source: §II · p. 2

III. AGENTS AND TOOLS

  • The next section defines the terminology used to describe systems assembled from smaller units.Source: §III · p. 2

A. Invocation and Tools

The section defines LLM-integrated systems through agents and tools, then distinguishes recurring architectures by how they organize agent calls and control execution.

A. Invocation and Tools

  • An LLM emits a parameterized tool call, while the surrounding system executes it and may return the result for a further model invocation.Prompts must specify when and how tools apply.Source: A. Invocation and Tools · p. 2

B. AI Agent

  • An AI agent is a prompt-and-response system component, whether or not it has access to tools.The paper adopts this minimal definition despite variation in field usage.Source: B. AI Agent · p. 2

C. Monofunctional and Multifunctional Agents

  • A monofunctional agent performs a delimited function, whereas a multifunctional agent selects among functions and decides how to execute them.The paper treats these as endpoints on a continuum; multifunctional agents typically select and parameterize tools autonomously.Source: C. Monofunctional and Multifunctional… · p. 2

D. Architecture Patterns

  • Workflows follow a predefined sequence of process steps, while router-worker systems route inputs to specialized workers for predefined tasks.Workflow sequences may branch conditionally but are not dynamically composed by a model.Source: D. Architecture Patterns · p. 3
  • Orchestrator-worker systems have a manager decompose tasks and delegate subtasks; planner-executor systems iteratively revise plans using worker feedback.Planner-executor designs may be hierarchical, with subordinate planners refining high-level subtasks.Source: D. Architecture Patterns · p. 3
  • In ReAct, one multifunctional agent alternates reasoning and tool use until it judges the task complete, and tools may include subagents.The number of calls per task is determined by an LLM in architectures such as orchestrator-worker, ReAct, and planner-executor, unlike fixed-call workflows or router-worker systems.Source: D. Architecture Patterns · p. 3
  • Guardrail agents supervise safety or compliance but are treated as cross-cutting concerns, not architectural elements or task-solving calls.In deployed MAS case studies on one framework platform, orchestrator-worker and router-worker are the most frequent architectures.Source: D. Architecture Patterns · p. 3

IV. FORMS OF LLM-INTEGRATED APPLICATIONS

This section introduces established forms of LLM-integrated applications through examples.

  • The section describes established forms of LLM-integrated applications by examples.Source: §IV · p. 3

A. LLM Chats

LLM chats provide a dialogue interface, custom agents package recurring tasks, and RAG augments chat with external knowledge sources.

A. LLM Chats

  • LLM chats provide dialogue interfaces for drafting, translation, and search-like use, while users or the model may initiate tool use.Chat products may route turns across models and offer deep research as a tool.Source: A. LLM Chats · p. 3

B. Custom Agents

  • Custom agents store prompts for recurring tasks, may attach tools, and are commonly limited to host-service capabilities rather than external integrations.Guidance recommends a delimited task scope, and custom agents can also serve as workflow steps.Source: B. Custom Agents · p. 3

C. Retrieval-Augmented Generation

  • RAG retrieves passages from external knowledge sources to ground generated answers and make supporting material checkable.It can expose sources such as internal documents or specialized domain expertise that were not included in model training.Source: C. Retrieval-Augmented Generation · pp. 3–4

1) Narrow Sense RAG:

Narrow-sense RAG retrieves prepared document chunks before generation, while agentic RAG uses agents to decide what to retrieve; workflows embed agents in prescribed processes.

1) Narrow Sense RAG:

  • Narrow-sense RAG embeds chunks from a prepared vector database, selected by similarity to the user's question, into the prompt for answer generation.The LLM does not perform retrieval in this form.Source: 1) Narrow Sense RAG · p. 4

2) Agentic RAG:

  • Agentic RAG uses retrieval mechanisms such as web search or database queries as tools, with agents deciding what to retrieve.Its architectures range from single-agent loops to multi-agent and hierarchical designs; detailed study of agentic RAG products and deep-research systems is beyond scope.Source: 2) Agentic RAG · p. 4

D. AI-Enhanced Workflows

  • AI-enhanced workflows extend established RPA and business-process platforms with agent-invoking blocks, including for drafting, summarizing, or routing messages.Some platforms support self-hosting and arbitrary models, including local models, for strict data-protection requirements such as public administration.Source: D. AI-Enhanced Workflows · p. 4
  • These workflows typically run unattended after event- or schedule-based triggers, with human inspection limited to configured checkpoints.Developer-oriented agentic-workflow frameworks and visual builders allow more flexible MAS architectures than prefabricated low-code blocks.Source: D. AI-Enhanced Workflows · p. 4

E. Copilots

The survey examines commercial products and research prototypes labeled copilots, drawing on vendor documentation, system inspection, and an interview study. Commercial examples show orchestration engines, task-specific capabilities, and workers that operate host applications.

E. Copilots

  • Vendor documentation, direct system inspection, and an interview study with engineers building product copilots inform the survey of their common characteristics.The documentation was often not very detailed.Source: E. Copilots · p. 4

1) Commercial Copilots:

  • An office-suite copilot combines a language model with applications and business data, while CRM capabilities draft replies, curate customer segments, and generate product descriptions.Users decide what to keep, modify, or discard; another CRM vendor describes a reasoning engine selecting task-delimited actions from a library.Source: 1) Commercial Copilots · pp. 4–5
  • An ERP assistant’s workers execute procurement tasks such as creating requisitions and changing purchase orders without users opening the respective applications.Each capability is documented separately with its own APIs and semantic object-action pair.Source: 1) Commercial Copilots · p. 5
  • An industrial copilot has an orchestrator delegate to specialized agents, while a programming copilot lets users invoke skills and requires developer review before generated code is compiled or executed.The industrial agents can plan and execute actions independently, while users retain control over which tasks to delegate.Source: 1) Commercial Copilots · p. 5

2) Research Prototype Copilots:

Research prototypes show copilots operating applications or coordinating analyses, while the surveyed characteristics describe visible, user-refinable host-application actions. The label agent is associated with AI-planned multi-step execution whose outcome, rather than each step, is shown to users.

2) Research Prototype Copilots:

  • A product-configuration copilot translates natural-language input for a constraint resolver, with users able to see and correct the effect immediately; an agricultural copilot coordinates platform tools and processing steps through a predefined meta-program graph.The product-configuration case supports only one intent and does not require routing.Source: 2) Research Prototype Copilots · p. 5
  • A manufacturing-equipment copilot uses a further model invocation to check a worker’s selection and consults the user only if that check fails.The system accesses knowledge but does not operate further application software.Source: 2) Research Prototype Copilots · p. 5

3) Characteristics of Copilots:

  • Typical copilots visibly operate existing applications through a router-worker pattern, letting users keep or refine each operation and sometimes offering contextual action buttons.The user states a goal, the copilot detects intent, and specialized workers carry it out.Source: 3) Characteristics of Copilots · p. 5

4) Shift of Labels:

  • Vendors’ shift from copilot to agent coincides with a move from user-confirmed single steps to AI-planned multi-step execution whose outcome the user sees.Vendor examples include an announced move from “just AI copilot” to “AI orchestrator” and “dynamic multi-step plans.”Source: 4) Shift of Labels · p. 5

F. Coding Agents

The paper describes coding agents and a multi-agent research feature, then summarizes selected systems using shared structural dimensions. Its discussion frames the work as investigating emerging system forms and their characteristics.

F. Coding Agents

  • Coding agents are built around an agentic loop that delegates work to subagents, a pattern also used by GitHub Copilot’s agent mode.The passage identifies sources, – for coding agents and for the agent mode.Source: F. Coding Agents · p. 5

G. Planner-Executor Example System

  • Anthropic’s Research feature uses a lead agent to plan research, delegate parallel subtasks, synthesize findings, and decide whether further research is needed.Its subagents search, evaluate intermediate results, and reformulate queries; planning is interleaved with execution rather than completed up front.Source: G. Planner-Executor Example System · p. 5

H. Summary of Selected Systems

  • Table II summarizes system forms and instances without an established form across architecture, user intervention, agent calls per task, and available tools.The entries draw on vendor documentation for commercial products and peer-reviewed descriptions for research prototypes.Source: H. Summary of Selected Systems · p. 6, Table II · p. 6

V. DISCUSSION

  • The study asks which structurally similar forms have emerged and whether system labels denote forms, examining architecture, user control, agent calls per task, and tool use.These structural characteristics are intended to make it possible to describe systems in newly developed application areas.Source: §V · p. 6

A. Scope and Granularity

The study offers a general framework for describing and positioning LLM-integrated systems, not a fine-grained design space or mutually exclusive taxonomy. It also discusses label distinctions and how to represent nested architectures.

A. Scope and Granularity

  • The study characterizes systems at a general level rather than providing mutually exclusive categories, a fine-grained developer design space, or an instrument for detailed architectural research.Its stated purpose is an accessible framework for practitioners, students, and newcomers to position and label systems using common terms.Source: A. Scope and Granularity · p. 6

B. Labels and Architectural Distinctions

  • The vendor shift from copilot to agent marks a move from user-confirmed single steps to AI-planned multi-step execution, with users seeing only the outcome.The survey also found that coding agents from four major providers are structurally similar.Source: B. Labels and Architectural Distinctions · p. 6
  • For narrow-sense RAG, the study derives characteristics from the original formulation but does not investigate whether branded products or prototypes conform to it.The paper introduces “AI-enhanced workflow” as its own label because, to the author’s knowledge, no common label exists for that form.Source: B. Labels and Architectural Distinctions · p. 6

C. Nested and Hybrid Architectures

  • Nested and hybrid architectures are possible, as in the Equipment Selection Copilot, whose user-facing router-worker system contains a worker implemented as chained model invocations.The passage notes that diverse, hybrid, and nested architectures are common.Source: C. Nested and Hybrid Architectures · p. 6
  • For nested systems, the paper suggests classifying at the user-facing level and recording internal nesting as a property of the workers.It expects more chat- and copilot-type systems to gain multi-agent-system workers and tools.Source: C. Nested and Hybrid Architectures · p. 6

D. Limitations and Future Work

The paper’s descriptions are limited by single-author characterization, reliance on vendor sources for some systems, and a field that changed substantially during the study. It presents the classification as a basis for comparing systems and making their terminology more accessible, while identifying extensions to new forms and non-LLM AI as future work.

D. Limitations and Future Work

  • The corpus is illustrative, so it supports no frequency claims; single-author characterization and vendor sources also constrain some system descriptions.Independent second coding and technical rather than promotional sources would strengthen the observations.Source: D. Limitations and Future Work · pp. 6–7
  • The study’s descriptions reflect a changing field, and future work could extend them to emerging forms, Deep Research, Agentic RAG, and non-LLM AI systems.The paper notes that copilots acquired capabilities now marketed as agents and AMAS moved from research prototypes to commercial offerings.Source: D. Limitations and Future Work · p. 7

VI. CONCLUSION

  • The paper describes six system forms in full and a seventh in part, using architecture, human role, agent-call count, and tool use as shared dimensions.The survey illustrates these descriptions with 22 systems characterized from vendor sources, inspection, video, and secondary sources.Source: §VI · p. 7
  • The classification is intended to make the field more accessible, help practitioners compare technologies, and introduce emerging terminology into research literature.The conclusion notes that many routinely used labels lack uniform descriptions of how the systems are built, with RAG as an exception.Source: §VI · p. 7
Loading 2610.11899v1…