Agentic AI: A Deep Dive

For much of AI’s history, the difficult part was turning a useful idea into a system that could handle unfamiliar situations. Today’s agents extend language models with tools and feedback. Understanding that shift helps explain what they can do, why computing infrastructure matters, and where human control still belongs.

Why did AI move from rules to models that can use tools?

Early artificial intelligence tried to make aspects of reasoning explicit in software. The 1955 proposal for the Dartmouth summer research project already connected language, learning, abstraction and self-improvement. It also warned that hardware capacity was not the only obstacle: researchers needed better ways to use it.[7]

A rule-based program is effective when someone can describe the relevant conditions and actions. “If this field is empty, reject the form” is clear and testable. But imagine writing every rule needed to recognise a cat in photographs, understand a differently phrased question, or decide whether two technical documents contradict each other. The difficulty is not simply executing more rules; it is deciding what those rules should be.

Machine learning changes the approach: instead of specifying every decision, we fit a model to examples. A model is the learned mathematical system used to make predictions or generate outputs. Deep learning uses neural networks with multiple processing layers to learn increasingly useful representations of the input. These approaches did not make explicit rules obsolete; they made different kinds of problems tractable.

The longer history contains several different approaches—not just a straight path to today's language models. This timeline provides a map before we focus on the recent breakthroughs.

Selected milestones in AI research, shown in chronological order. Spacing is illustrative rather than proportional to elapsed years.[83][81][82]

A useful milestone is the 2012 ImageNet paper by Alex Krizhevsky, Ilya Sutskever and Geoffrey Hinton. It combined a deep neural network, a large labelled image dataset, techniques to improve training, and an efficient graphics processing unit (GPU) implementation. Its significance here is the combination: data, algorithms and hardware working together, not a chip independently becoming intelligent.[8]

Language brought another challenge: relationships between words may span a sentence or a much longer passage. In 2017, Attention Is All You Need introduced the transformer, an architecture based on attention mechanisms that let it relate different positions in a sequence. Its design also allowed more parallel training than the recurrent approaches compared in the paper.[3]

Large language models (LLMs) build on this broader development: they learn patterns from extensive training data and generate language from the context supplied to them. The 2020 GPT-3 paper demonstrated that many tasks could be specified through instructions and examples in a prompt, without separately updating the model’s parameters for each task. Subsequent instruction training and training with human feedback helped make models more useful as assistants.[4][44]

How have AI models become more capable?

Successive model generations have expanded both the range of tasks they can attempt and their performance on difficult tasks. Behind that progress is a physical system: research teams, training data, specialised chips, large computing clusters and the electricity needed to keep them running.

An AI model learns numerical parameters—often called weights—that determine how it transforms inputs into outputs. It does not contain a separate hand-written program for every question. Once trained, the same language model can be prompted to explain a concept, compare product descriptions or help write a program. To understand why those abilities keep improving, we need to distinguish who develops the model from who supplies the infrastructure.

What are AI labs and hyperscalers?

An AI lab develops models: it researches architectures, prepares training data, runs training experiments and evaluates the results. A hyperscaler operates large-scale cloud and data-centre infrastructure. The lab needs computing capacity; the infrastructure operator supplies some or all of the machines and services that provide it.

OpenAI, Anthropic and Google DeepMind are examples of organisations developing major model families. Amazon Web Services, Microsoft Azure, Google Cloud and Oracle Cloud Infrastructure operate cloud infrastructure that can support AI workloads. The roles can overlap: Google develops models, designs its own tensor processing units (TPUs) and operates cloud infrastructure. “AI lab” and “hyperscaler” describe roles, not mutually exclusive types of company.[25][26][79]

A lab might build its own cluster, obtain capacity from a cloud provider, or use several partners. A cluster is a group of connected computers working together. For large AI workloads, specialised processors called accelerators handle much of the numerical work. Graphics processing units (GPUs) are a widely used kind; Google's TPUs are another. Oracle, for example, offers GPU infrastructure for both model training and inference.[70][79]

How do labs train an AI model?

Training repeatedly gives a model examples, measures its errors and adjusts its weights to improve its predictions. Large-scale training distributes that numerical work across many accelerators. After broad pre-training, additional training and evaluation can make the model more useful for instructions, reasoning and particular applications.

For a language model, a simplified training cycle is:

1. Prepare the data. Select and process training material, then encode it as tokens: the text units the model processes.
2. Make predictions. During pre-training, the model learns to predict tokens from their context. When training starts from scratch, the initial weights do not yet provide useful language ability.
3. Measure and reduce error. A loss function measures how the predictions differ from the target. Backpropagation computes gradients—how the loss changes as the weights change—and an optimiser uses them to update the weights.
4. Repeat at scale. Process many batches of examples, coordinating computation and exchanging information across the cluster. Save checkpoints so training can resume rather than restart after a failure.
5. Post-train and evaluate. Use techniques such as instruction examples, preference feedback and reinforcement learning, then test the model's capabilities and limitations before release.[4][44][78]

The accelerators must exchange information efficiently, not just perform arithmetic independently. NVIDIA’s collective-communication library, for example, supports the multi-GPU and multi-node communication used to scale neural-network training. Faster chips alone are not enough if memory movement or communication holds the cluster back.[47]

Inference is the later use of the trained model to answer a request. Training builds its learned capabilities; inference applies them. But a short definition and a difficult debugging problem need not receive the same amount of computational work. This is where reasoning models and test-time compute become useful.

What are reasoning models and test-time compute?

Reasoning models are trained to work through difficult problems using intermediate reasoning steps. Test-time compute is the computation spent solving a request during inference. Allocating more of it can improve some answers without increasing the model's parameter count.[53]

OpenAI's o1 research, for example, used reinforcement learning to teach strategies such as breaking problems into smaller steps and reconsidering an approach. Training develops those strategies; test-time computation applies them to the request at hand.[53]

Extra computation can go into a longer reasoning process, or into generating several candidate solutions and comparing them. These are different techniques. A longer visible answer is not, by itself, evidence of more or better reasoning.[53][107]

Some APIs expose a reasoning-effort setting. Higher effort can help with difficult debugging or planning, but generally increases latency and token use. OpenAI's API bills hidden reasoning tokens as output tokens, so even a short final answer can involve substantial work. Available settings depend on the model.[107]

A hard-to-reproduce bug may justify more computation than formatting a short message. Evaluate correctness, waiting time and total cost together; additional reasoning does not guarantee a correct result.

But a model cannot reason about evidence it never receives. A screenshot, a spoken explanation or a video may contain details that a text-only description leaves out. Working directly with those inputs calls for multimodal models.

What are multimodal models?

Multimodal models work with more than one kind of data, such as text, images, audio or video. Supported input and output types vary: a model may analyse images and produce text without being able to generate images itself.[108][109][110]

During software development, that might mean supplying a screenshot of a broken layout alongside an error message, or asking about a screen recording of an intermittent failure. The visual evidence complements the code and logs; it does not replace a test of the running application.

Input understanding and output generation are separate capabilities. Google's documentation, for example, describes audio analysis that produces text responses, while its model catalogue also includes specialised image, speech and video generation models. Check both what the selected model can receive and what it can produce, through the interface you actually use.[109][27]

Media also has a computational cost. Google's image guide notes that higher resolution can improve the recognition of fine text and small details while increasing token use and latency. Supplying a clear, relevant image is a different engineering choice from allocating more reasoning effort to interpret it.[108]

Working with text, images or audio tells you what a model can do, but not where you can run it. If you want to operate the model yourself rather than only send requests to its developer, you need access to its trained weights. That is the role of open-weight models.

What are open-weight models?

An open-weight model makes its trained parameter files available to download and run under a licence. That gives you a deployment option beyond the developer's hosted API. It does not automatically include the training data, complete training pipeline or unrestricted usage rights.[112][113]

The practical advantage is choice: use a hosted endpoint or operate the model yourself, subject to the licence. Self-hosting also makes capacity planning, software updates and serving reliability your responsibility. Downloadable weights do not make the hardware or its operation free.

Moonshot AI, the company behind Kimi, illustrates this approach. Its Kimi K3 has published weights and native vision capabilities. Kimi K3.1 Pro is a post-trained version of K3, developed with more post-training compute for coding and other agentic work.[112][111]

Release status matters. As checked on 26 October 2026, Moonshot's announcement makes K3.1 Pro available through its applications and API, while promising the full weights by 4 November 2026. Hosted access is available before the announced weight release; they are not the same milestone.[111]

Licences also differ. Kimi K3 uses its own licence, with additional conditions for some model-as-a-service businesses. Check the licence attached to the exact release rather than assuming all open-weight models have identical terms, or that a successor inherits its predecessor's licence.[113]

Having the files is only the first step. To generate responses, you need compatible inference software—the software that loads the weights and runs the model—and hardware with enough memory and computing capacity. That makes local hardware the next practical choice.

What hardware can run models locally?

Smaller models can run on a suitable laptop or desktop; larger ones may need more accelerator memory or several machines. The practical limit depends on the full model, its numerical precision, the context you need and the inference software—not just a processor's headline performance.

Quantisation stores weights at lower precision to reduce their memory footprint, with possible accuracy trade-offs. As a simple illustration, eight billion parameters stored at four bits each need about 4 GB for weights alone. You still need room for the model's context cache, runtime buffers and other software; fitting the weights is not the same as obtaining fast responses.[116]

For developers who want a dedicated desktop system, NVIDIA DGX Spark combines a GB10 Grace Blackwell chip with a 128 GB unified-memory configuration, shared by its CPU and GPU. NVIDIA advertises inference with models up to 200 billion parameters. Treat this as a capacity claim whose usefulness depends on precision, model support and workload—not a guarantee that every such model or context configuration will fit or run quickly.[114]

DGX Spark beside a laptop: dedicated model-computing hardware in a desktop-sized system. Image: NVIDIA.[115]

This does not mean every Kimi model fits on one Spark. Moonshot lists Kimi K3 at approximately 2.8 trillion total parameters, with 104 billion activated during processing. Its mixture-of-experts design activates only part of the model for each token; the other weights still have to be stored somewhere.[112] Even an illustrative four-bit representation of all 2.8 trillion parameters would require roughly 1.4 TB for raw weights alone, before overhead. That complete weight set does not fit in one 128 GB Spark's unified memory.

For a single desktop, start with a smaller supported model and test it at the context length and response speed you actually need. Check that the inference engine supports the model architecture, weight format and hardware. A successful download is not a deployment test.

Desktop systems make experimentation and selected deployments possible. Training frontier models and serving large workloads still require much larger pools of computing capacity. AI data centers bring that infrastructure together.

What are AI data centers?

AI data centers are physical facilities that bring together accelerator servers, fast networks, storage, electrical infrastructure and cooling to train and serve AI models. The building is only part of the system: its usefulness depends on making all of those components work together.

Training and inference are software processes, but at large scale they need an industrial operating environment. Four supporting systems matter:

• Compute and memory. Accelerator servers perform the numerical work; their memory holds the model state and data needed during computation.
• High-speed networks. Accelerators exchange information during distributed training. A cluster is not simply a collection of independent fast chips: communication can become the bottleneck.[47]
• Storage and operations. Training data and checkpoints need to be available when required, while operators must monitor failures and keep jobs recoverable.
• Power and heat removal. Electrical infrastructure supplies the racks, and cooling carries away their heat. Crusoe's Abilene design, for example, describes direct-to-chip liquid cooling; the electrical and cooling systems are part of delivering usable compute, not accessories.[96]

Abilene makes the scale tangible. In its March 2025 expansion announcement, Crusoe described an eight-building campus of approximately 4 million square feet—about 372,000 square metres—with a planned power capacity of 1.2 GW. These are announced full-campus design figures, not a measurement of current utilisation or electricity consumption. Crusoe identifies Oracle as the project's primary customer and strategic partner, with DPR Construction as the lead construction partner.[96][98]

Abilene during construction, published by DPR Construction. Roads, vehicles and repeated building groups make the scale visible. The acquisition dates of these project photographs are not independently confirmed.[97]

A closer aerial view of the buildings and surrounding installations. Photograph published by DPR Construction.[97]

The closer view below brings that industrial scale back to human dimensions: workers are installing exterior panels along a data-center building. It shows a part of the construction effort that disappears when we speak only about models, tokens and GPUs.

Workers installing exterior panels at Abilene. Photograph published by DPR Construction.[97]

AI capacity needs more than processors: chips, memory, packaging, servers, networks, electrical equipment and construction must come together. Next, we trace that supply chain from chipmaking to AI services.

How do ASML, NVIDIA and Oracle fit into the supply chain?

They operate at different layers. ASML supplies machines used to manufacture chips; NVIDIA designs accelerators and computing systems; foundries fabricate the silicon; memory and packaging make usable components; server and cloud infrastructure brings them together. AI labs use that capacity to train and serve models.

Read from bottom to top: chipmaking equipment supports the components, infrastructure and software above it. Companies can operate across several layers.

• Design and upstream inputs. Chip designers work with design software and intellectual property; manufacturing also needs silicon wafers, chemicals, materials and specialised equipment. These are separate capabilities, not activities performed by one company.
• Manufacturing equipment — ASML. Lithography machines help pattern the circuits on silicon wafers. ASML supplies the equipment and supporting technologies to chipmakers; it does not manufacture finished NVIDIA GPUs.[68][77]
• Chip design and fabrication — NVIDIA and foundries such as TSMC. NVIDIA develops accelerator architectures and systems, while manufacturing partners fabricate the silicon. NVIDIA's Blackwell Ultra description, for example, identifies TSMC's 4NP manufacturing process.[69]
• Memory, packaging and testing. Compute dies need memory and connections. High-bandwidth memory (HBM) supplies data close to the accelerator; advanced packaging integrates components so they can communicate efficiently. A shortage of memory or packaging capacity can limit delivery even when the processor design is ready.[69][72]
• Servers, networks and cloud capacity. Components become server and rack systems, connected by high-speed networks and supported by power and cooling. Oracle and other cloud operators make such computing capacity available to customers. Oracle belongs at this infrastructure layer—not in the chip-fabrication box.[70]
• Models and applications. AI labs use the infrastructure for training and serving models. Agent developers then build applications around those models, connecting them to tools and users.

Two photographs make these layers tangible: the equipment used to pattern chips, and NVIDIA hardware presented on stage.

ASML's TWINSCAN NXE:3800E EUV lithography system in Veldhoven. Photograph: Michel de Heer / ©ASML.[104]

Jensen Huang presenting NVIDIA hardware in Taipei on 2 June 2024. Photograph: Annabelle Chih / Bloomberg / Getty Images.[140]

The supply chain explains how accelerators reach a data center. Their design determines how efficiently they turn that infrastructure into useful work. For an interactive agent, a particularly important question is how quickly a trained model can produce its next response. That is driving specialised inference architectures such as Cerebras' wafer-scale systems.

Why can specialised chips make inference much faster?

Inference can be limited by moving data, not just performing calculations. Specialised designs keep model weights close to compute, reduce communication overhead and organise execution around token generation. Their advantage depends on the model, workload and serving system—not a universal ranking of chips.

A model first processes the prompt, a stage called prefill, and then generates its response during decoding. In ordinary autoregressive decoding, each new token depends on what came before it. At low batch sizes, compute units can spend much of their time waiting for model data rather than doing arithmetic. Faster access to weights and intermediate state can therefore matter as much as more arithmetic units.[137]

Cerebras changes the physical scale of the processor. Instead of cutting a wafer into many separate processors, its Wafer-Scale Engine keeps a very large grid of compute cores and memory connected on the silicon. Cerebras describes its GPT-5.6 Sol implementation as using 44 GB of on-chip static random-access memory (SRAM) per wafer, with weights kept on-chip and model layers pipelined across multiple wafers. SRAM is fast memory integrated with the compute.[130]

This reduces repeated movement from external memory and avoids some of the communication and coordination required between separate accelerator chips. It does not eliminate networking: when a model spans several wafers, activations still pass between them. Cerebras' Hot Chips 2026 explanation describes keeping high-volume tensor and expert communication on-wafer while transferring lower-volume activations between systems.[129]

A Cerebras wafer-scale chip held in gloved hands, illustrating the scale of the silicon. Archival press photograph: © Cerebras Systems, Inc.; the photographed generation is not identified here.[135]

Different architectures tackle the same bottleneck in different ways:

• Cerebras: wafer-scale compute, on-chip SRAM and short on-wafer connections. Its CS-4 system uses the Nexus rack platform with three Wafer-Scale Engines. The roadmap also describes CS-5, targeted for 2027, and CS-6 with tightly integrated, 3D-stacked DRAM to add memory capacity. Those roadmap claims are plans, not measurements of deployed CS-5 or CS-6 services.[129]
• Groq's Language Processing Unit (LPU) approach: on-chip SRAM and compiler-controlled, deterministic execution. The compiler schedules computation and data movement to reduce unpredictable delays, rather than simply relying on a higher peak arithmetic specification.[136]
• NVIDIA GPUs: high-bandwidth memory, NVLink GPU interconnects and a programmable platform whose kernels and serving software can keep improving. GPUs can be reused across training and inference, and software optimisation can substantially change performance without replacing the entire hardware fleet.[69][133]

The term “fastest” therefore needs a workload attached. Time to first token measures the initial wait; output tokens per second measures generation once it starts; aggregate throughput measures how much a service can handle across requests. Comparisons need matched models, context lengths, precision and load; even tokenisation can differ between models. A low-latency system for one interactive session is not automatically the cheapest or highest-throughput choice for a large batch. For an agent, the final measure is task-completion time—including tool calls, tests and retries—not token speed alone.[137]

How does OpenAI use Fast and Ultrafast inference?

OpenAI exposes faster serving through service tiers, including Fast and Ultrafast. These are delivery options for supported models, not names for one chip architecture. The hardware must be checked for each model and offering: a Cerebras-backed tier and a GPU-backed tier can share the Ultrafast label.

The distinction is concrete:

• GPT-5.6 Sol Ultrafast on Cerebras. The August 2026 announcement described up to 750 output tokens per second, or up to 14 times Standard processing speed, initially in a limited preview. This is a specific model-and-service result, not a speed guarantee for every model served by Cerebras.[138][130]
• GPT-6 Astra Ultrafast on NVIDIA Blackwell. NVIDIA's October 2026 announcement explicitly identifies Blackwell GPUs and reports up to eight times faster token generation than Astra Standard. It credits improvements to inference software and kernels, including optimisation work assisted by OpenAI's own models. It would therefore be incorrect to attribute Astra Ultrafast's acceleration to Cerebras.[133]

For API users, Fast is selected with service_tier: "fast"; the older "priority" value is also supported. Ultrafast uses service_tier: "ultrafast" and is currently documented for GPT-6 Astra and GPT-6.1 Sol. It has separate rate limits and higher costs. A faster service tier is also different from reducing reasoning effort: one changes how the model is served, while the other changes how much reasoning work it is asked to do.[131][132]

The surrounding application still matters. OpenAI recommends persistent WebSocket connections for rapid sequences of agent tool calls because repeated network overhead can erode the gains. Faster generation can shorten an edit–test–fix loop, but it does not make a slow test suite, external API or human approval instant.[132]

These examples concern inference: using a trained model repeatedly. Training is a different workload with its own scaling story. To compare training runs across model generations, we first need a unit for that work.

How much has training compute grown?

Training compute is the total numerical work used to train a model. Estimates for selected large language models have increased by many orders of magnitude. These estimates describe individual training runs, not the entire computing fleet owned by a lab or its cloud partners.

A FLOP is a floating-point operation. FLOP/s, often written FLOPS, measures operations per second:

• 1 TFLOP/s = one trillion operations per second.
• 1 PFLOP/s = one thousand TFLOP/s.
• 1 EFLOP/s = one thousand PFLOP/s.

The distinction matters: FLOP is an amount of work; FLOP/s is a rate. Hardware specifications usually give a theoretical peak rate at a stated numerical precision. Actual training throughput also depends on utilisation, memory movement, communication and interruptions. FP8, FP16 and other formats use different numerical representations, so their advertised throughput figures are not interchangeable.[32][69]

Source: Epoch AI's model database, retrieved 26 October 2026. One illustrative model per publication year; not annual maxima, a complete industry series or vendor fleet totals. Points mix paper-supported values and indirect estimates. Hollow markers identify the indirect estimates selected here. Publication year is not necessarily the year the training occurred; connecting lines only guide the eye.

For scale, Epoch records approximately 3.14 × 10²³ FLOP for GPT-3 and estimates 9.4 × 10²⁶ FLOP for GPT-6 Astra. The latter is an indirect estimate, with a range of roughly 5 × 10²⁶ to 2 × 10²⁷ FLOP in its estimation notes—not a disclosed meter reading from OpenAI. The difference between those selected points is about 3,000-fold in training work, not a claim of 3,000-fold intelligence.[58]

A deliberately hypothetical example makes the units tangible: 100,000 accelerators each sustaining 1 PFLOP/s would together deliver 100 EFLOP/s. Running continuously for 90 days would perform about 7.8 × 10²⁶ FLOP. This is arithmetic illustrating scale, not an inventory or performance claim about any provider. It also does not tell us electricity use without a separate power measurement.

Compute measures the work done during training. The model that comes out of that process has another kind of scale: how many learned parameters it contains.

Does a higher parameter count mean a better model?

Parameter count measures the number of learned numerical values in a model, not its intelligence. Larger models can offer more capacity, but training data, architecture and training quality also matter. Newer models can be smaller and still perform better on important tasks.

Total parameter counts as recorded in Epoch AI's database. The examples are selected, not the largest model of each year. Kimi K2 and K2.5 use mixture-of-experts architectures; their total weights are not all active for each token. No undisclosed GPT-4, GPT-5 or GPT-6 parameter count has been filled in with speculation.

A dense model uses its main network throughout processing. A mixture-of-experts (MoE) model routes work through a subset of specialised parts. For example, Epoch records Kimi K2 as having one trillion parameters in total but about 32 billion active per forward pass. Comparing its total parameter count directly with the active computation of a dense model would be misleading.[58]

The dips reflect the selected examples, not changes in the largest available model. The Chinchilla research demonstrated that a smaller model trained on more data could outperform a larger model trained with the same compute budget. Scale matters, but so does how that scale is used.[5]

Neither training compute nor parameter count tells us which tasks a model can complete. For that, we need to look at changes in behaviour and performance.

What has changed in the models' abilities over time?

Capability has broadened from flexible text generation towards better instruction following, visual understanding and more demanding reasoning. These are overlapping advances, not a fixed ladder every model climbs. A model's performance should still be checked on the tasks and conditions that matter to its user.

The change becomes clearer when we look at a few milestones:

• 2020 — Learning from examples in a prompt. The GPT-3 paper demonstrated that one language model could attempt many tasks from written instructions and a few examples, without a separate parameter update for each task.[4]
• 2022 — Becoming more useful as an assistant. InstructGPT research used demonstrations and human preferences to improve instruction following. This was a change in how models were trained to respond, not simply an increase in size.[44]
• 2023 — Working with images as well as text. The GPT-4 technical report described a model that accepts image and text inputs and produces text outputs. A model could now be asked about visual material, rather than relying only on a typed description.[52]
• 2024 — Spending more computation on difficult reasoning. OpenAI's o1 research described training models to work through harder problems and reported better performance with more training and more computation at answer time. A fast reply and a more deliberative reply became meaningful design choices.[53]
• 2025 — Stronger problem solving and coding. OpenAI's GPT-5 developer evaluation reported gains over earlier models on difficult science questions, competition mathematics and coding tasks. These are OpenAI-reported benchmark results, not just more fluent conversation.[51]
• 2026 — Coordinating agents on frontier research. OpenAI reports teams of agents using an internal model to investigate Millennium Prize Problems, including a reported Navier–Stokes proof. This extends the story from individual model responses to sustained, tool-assisted research.[94]

Selected milestones, not a complete history or claims that each capability was invented in that year. The examples mainly follow one research lineage to keep the progression readable; other labs contributed parallel advances. New releases do not improve every task equally.

What does the 2026 milestone show?

Frontier research systems are being used to coordinate many model-driven workers on open scientific problems. OpenAI's published Millennium Prize effort is a concrete example: the capability being tested is sustained, tool-assisted collaboration, not merely answering harder benchmark questions.[94]

On 8 September 2026, OpenAI reported using an internal model in coordinated groups of agents to investigate open Millennium Prize Problems. The agents could read a cached version of the internet, run code and communicate within their groups. Researchers varied the prompts, redirected effort and consolidated intermediate findings across groups. This was an orchestrated research system, not an unattended chatbot receiving one question.[94]

OpenAI reported a Navier–Stokes result concerning finite-time singularities in three-dimensional incompressible flow with a smooth external force, and published both a proof write-up and a formalization in Lean, a system for expressing and checking mathematical proofs. According to its account, the group that produced this result involved roughly 10,000 concurrent agents. The internal model used was distinct from its publicly available model at the time.[94]

Keep the claim's scope clear. This is OpenAI's published research report, not a claim here that a consumer chatbot can solve arbitrary open problems or that all Millennium Prize Problems have been solved. The Clay Mathematics Institute currently lists Navier–Stokes as Active, rather than among its solved problems; OpenAI also says it does not intend to claim the prize. A lab announcement, mathematical scrutiny and formal prize recognition are different things.[94][95]

This example expands what researchers can attempt, but it does not provide a single measure of intelligence. To compare models more broadly, we need evaluations that go beyond one research result.

What does “more intelligent” mean in practice?

Here, intelligence refers to capabilities such as applying knowledge, solving unfamiliar problems and combining constraints. Benchmarks provide imperfect ways to measure those abilities. A useful historical comparison needs consistent methods; parameter counts, computing capacity and a model's confident tone are not substitutes for capability evidence.

The Epoch Capabilities Index (ECI) combines results across multiple benchmarks into a common statistical scale. This helps compare models as individual tests become too easy. The scale is arbitrary—not human IQ, a percentage or a measure on which twice the score means twice the intelligence.[61][62]

Derived from Epoch AI's 26 October 2026 snapshot. Each point is the highest central ECI score among covered models released that year; 2026 is incomplete. Error bars show the selected model's reported 90% bootstrap interval, not uncertainty in the whole year's frontier. Close or overlapping scores do not establish a decisive winner. The index combines results reported by benchmark creators, Epoch AI and model developers; historical scores can change as the dataset is refitted.

This snapshot places the selected annual points at approximately 125.7 in 2023, 141.7 in 2024, 156.3 in 2025 and 168.8 in 2026 so far. It illustrates rising measured capability, not a universal annual growth rate. In the 2026 data, the central scores of Claude Opus 5.5 and GPT-6 Astra are almost identical and their intervals overlap; the chart is not evidence that one is meaningfully superior.[67]

A complementary view comes from Artificial Analysis, an independent source of model evaluations and inference-performance data. Its Intelligence Index v4.3.2 combines ten evaluations across agentic work, coding, general capability and scientific reasoning. This gives readers another way to compare models rather than relying only on claims from their developers.[127][128]

Original visualisation using Artificial Analysis Intelligence Index v4.3.2 data from 26 October 2026. The same ten leading entries from the site's default selection are shown, with the reported rounded scores and reasoning/fallback labels. † marks a model without a publicly available API in that snapshot. Data: Artificial Analysis.[134]

The two charts answer different questions: the ECI view illustrates a historical trend, while this Artificial Analysis view compares selected models under one benchmark methodology. Their numerical scales are not interchangeable. The Intelligence Index is also primarily an English-language, text-based evaluation suite; it is not a complete measure of multimodal ability or performance on your own workload.[127]

For software development, stronger capability may help a model understand a codebase and diagnose a failing test. Whether a particular implementation is correct still depends on tests and review. Delivering those capabilities at scale also depends on the power supply behind the model.

Why is electricity becoming an AI bottleneck?

A computing cluster is useful only when it can receive enough reliable power and remove the resulting heat. AI capacity can expand faster than grid connections, substations, generation and equipment supply chains. The constraint is often getting electricity to the right place in time—not merely generating more worldwide.

The International Energy Agency's 2026 report estimates that global data-centre electricity consumption reached 485 TWh in 2025 and projects approximately 950 TWh in 2030 in its Base Case. These totals cover all data centres, not just AI. The report projects faster growth in AI-focused data centres and describes tightening constraints in grid access, transformers, generation equipment and high-bandwidth memory.[72]

Source: IEA, Key Questions on Energy and AI, April 2026. The dashed line links the published 2025 estimate and 2030 Base Case projection; it does not represent annual observations.

Power and energy are different measures. Megawatts (MW) describe an instantaneous power level; terawatt-hours (TWh) describe energy consumed over time. A hypothetical facility drawing 100 MW continuously for a 365-day year would consume 0.876 TWh. A model's FLOP count cannot be converted into electricity consumption using one universal multiplier.

There are several bottlenecks at once. Grid connections and substations take time to build. AI racks concentrate substantial power and heat in a small space. Rapidly changing workloads create swings in demand. Locating a data centre near existing capacity can help, but local planning, water, environmental and affordability concerns also matter. The IEA warns that these physical and social constraints can slow expansion even when capital and demand are available.[72]

What are hyperscalers doing about the energy constraint?

Hyperscalers are combining long-term electricity procurement, new generation projects, grid partnerships, storage, more flexible workloads and more efficient infrastructure. These measures solve different problems. A signed power agreement does not immediately create a working grid connection, and a future reactor does not power a data centre today.

• Contracting electricity and supporting new supply. Long-term power purchase agreements (PPAs) help finance generation. Renewable electricity remains important, but matching an annual energy total is not the same as having low-carbon electricity available at that location every hour. The IEA reports growing commitments to renewables, nuclear and geothermal alongside continuing grid constraints.[72]
• Backing nuclear projects with long lead times. Microsoft's 2024 agreement with Constellation was a 20-year PPA supporting the planned restart of Three Mile Island Unit 1, announced as approximately 835 MW. Google's 2024 Kairos agreement targeted up to 500 MW from new small modular reactors, with the first reactor targeted by 2030 and further deployments through 2035. Amazon's Energy Northwest agreement supported a planned first phase of roughly 320 MW, with an option to expand to 960 MW. These are examples of announced commitments—not claims that those capacities are already operating.[65][63][64]
• Making demand more flexible. Google announced agreements with Indiana Michigan Power and the Tennessee Valley Authority to shift or reduce selected data-centre demand when the grid needs it. Flexible work can be scheduled differently from a live conversation that needs an immediate answer.[66]
• Adding storage and considering onsite generation. Batteries can help manage rapid power swings and support reliability. The IEA also describes proposed onsite gas generation, particularly in the United States, while warning about turbine supply, emissions, costs and technical constraints. Onsite generation is not an automatic escape from infrastructure limits.[72]
• Improving chips, software and cooling. Better utilisation and more efficient models reduce the resources needed for a given task. Cooling design also matters, but water and electricity savings are not identical: Microsoft's closed-loop cooling design avoids evaporating water, while its explanation acknowledges a nominal increase in energy use compared with its evaporative designs.[80]

Microsoft's agreement with Constellation connects this energy discussion to a specific place: Three Mile Island in Pennsylvania.

The Three Mile Island site, pictured on Constellation's Crane Clean Energy Center page. The restart project concerns Unit 1; Unit 2 is a separate facility. Photograph published by Constellation.[65][106]

The important relationship is therefore research progress plus manufacturing capacity plus usable compute plus energy infrastructure. More efficient models can lower energy per task while total demand still grows as more people use them and agents perform more steps. That is why the development of AI is simultaneously a software, semiconductor and energy story.

Yet an assistant that writes a convincing answer still has a practical limitation. It may need a current document, a calculation, or confirmation that an operation actually succeeded. Generating text about those things is not the same as doing them.

Tool-using agents address this gap by bringing external observations into the process. The 2022 ReAct paper explored interleaving language-model reasoning and actions, allowing observations from an environment to influence subsequent steps.[6]

What makes an AI system agentic?

An agentic system lets a model help choose an action, use a tool—such as inspecting a project file or running a test—inspect the result and continue towards a goal. The important change is the feedback loop, not a chatbot’s personality or the number of models involved.

A conventional build pipeline follows a predefined sequence: install dependencies, run tests and build the application. An agent can adapt its next step: inspect a failing test, trace the relevant code, make a correction and run the test again. Anthropic’s architectural distinction is useful: workflows follow predefined code paths, while agents let models dynamically direct parts of the process. Many useful systems combine both.[45]

Agency can be narrow. An agent might be allowed to inspect tests and propose a fix, while a person decides whether to merge it. The amount of autonomy should follow the task.

Consider this illustrative assignment: “Build a small online store with product pages, a basket and checkout. Use the payment provider’s test environment, and prepare the changes for review—not production deployment.”

The work is familiar: connect the product pages, basket and checkout, then check that a customer can complete an order. Failed payments and repeated requests need to be handled too.

In this example, the agent works in a development workspace with test payments. It inspects the existing project, clarifies important choices that are still open, then edits the code and runs checks. A developer reviews the changes before they go live.

A language model can describe those changes in a reply. Carrying them out requires software that can work with files and tools, then return the results to the model.

What software turns a model into an agent?

A model's reply cannot edit a file or run a test on its own. An agent runtime, or harness, connects the model to tools, executes permitted requests and returns their results. That surrounding software makes an interactive working loop possible.

For the checkout, the model might request a file change followed by a test run. The runtime sends those requests to the development tools and brings the output back. A failing test then becomes information the model can use to choose its next step.

Hermes Agent is one implementation of that runtime. It prepares the model's input, connects it to available tools and stores conversation state so the work can continue. The model supplies the reasoning; Hermes manages the surrounding loop.[9]

Where should the agent run?

An agent can run on a laptop, a server or a hosted platform. A laptop suits an interactive development session. Work that needs to remain reachable or start on a schedule benefits from an environment whose availability does not depend on that laptop.

When an agent is building software or handling another long-running task, you may want it to continue after you close your laptop. You may also want to pick up the work later from another device. That calls for a persistent, remotely accessible environment with the files, tools and task state kept together.

You can provide that environment yourself on a server. A managed agent platform brings together the operational pieces: running the harness, retaining its files, exposing interfaces and scheduling work.

One option is Agent37, an always-on agent platform with managed instances and templates for runtimes such as Hermes. In this example, Agent37 provides the host; Hermes continues to manage the agent loop, and the selected model supplies inference.[37][38]

The architecture below separates the hosted runtime and its local tools from the model providers and connected services it calls.

An illustrative logical deployment, not a map of a private installation or a security audit. The default sandbox, optional desktop and external services have distinct boundaries; hardening does not make authorised account access harmless.

• Execution and isolation. Agent37 describes its default instance type as gVisor-based, while full VM instances are a separate option. gVisor places an application-kernel boundary between sandboxed software and the host operating system, reducing exposure to the host kernel. That is a concrete isolation mechanism—not proof that every command, plugin or external action inside the instance is safe.[84][85]
• Persistent state. Files, project state and saved configuration can outlive a conversation. Agent37 preserves the home data directory across image updates; the operating-system layer is reset on an update. Keep durable agent data in that persistent location and treat backups, retention and recovery as separate responsibilities.[86]
• Browser and development tools. The stock Hermes template includes Chromium automation for opening pages, interacting with forms and inspecting results. A separate desktop-template recipe adds a visible browser that a person can watch and take over. For our example, those capabilities let the agent inspect a test checkout rather than infer its behaviour from source code alone.[87]
• Connected applications. Agent37's managed Composio service provides a route to supported external apps. OAuth lets a person authorise an application to access an account without handing that application their account password. Check the actual account and granted permissions: being able to discover a tool is not permission to execute every action it supports. Browser sessions and direct integrations are separate access paths, not automatically routed through Composio.[88]

Agent37 instances run continuously by default. With optional auto-sleep, an idle instance can pause and wake when a request arrives. Platform schedules can also wake it, unlike timers running inside a sleeping container. Durable task state belongs in files so it survives restarts.[92][93]

A hosted workspace solves the problem of keeping an agent available, but it leaves another choice: use an agent someone has already packaged for you, or choose the runtime, tools and operating rules yourself. Both approaches can support always-on agents, with different amounts of setup and control.

Which always-on agents and platforms can you use?

Ready-made agents combine models, memory, connected apps and background work in a product. Managed platforms host a runtime you configure; developer services provide building blocks for agents you build. Compare what continues between messages, what triggers new work and which actions still need approval.

Here, always-on means continuity, not that a model is generating tokens every second. A service may continue a long task, wake on a schedule or react to an event. Those behaviours differ from continuous monitoring, and persistent files do not imply an unlimited process lifetime.

The comparison below separates ready-made agents from managed hosts, agent builders and cloud runtimes. The latter can support an always-on application, but you still have to design its behaviour. Capabilities and access conditions are based on provider documentation checked on 26 October 2026, not hands-on testing of every product.

Access is not global. OpenAI's Pro rollout excludes the European Economic Area, Switzerland and the UK; Business Premium and Enterprise have separate workspace eligibility rules. Claude Duet starts with a US Pro/Max waitlist. Meta's later small-business announcement describes Muse as available in the US and Canada. Check the exact plan and region before treating any row as available to you.[117][118][120]

The operating behaviour matters as much as the label. Anthropic says Duet checks connected accounts every few hours, rather than continuously. Agent37 schedules can wake a sleeping instance, while an explicitly stopped instance stays stopped. AWS documents a maximum runtime-session lifetime and idle timeouts; durable state must be stored separately. These are different ways to manage work over time.[118][93][125]

For a morning brief or routine administrative work, start by checking whether a ready-made agent already has the right connections and approval behaviour. If you need to choose the harness and model or retain a development workspace, a managed platform gives you more of those choices. For an agent embedded in your own business application, a builder or cloud runtime may be the better starting point. Test the actual task, including pauses, approvals and recovery, rather than choosing on the promise of autonomy alone.

Whichever option you choose, you still need a way to give the agent tasks and receive its results.

How can you interact with your agent?

You can interact with an agent through a terminal, an editor, a web or desktop app, a chat service or an application interface. These are different ways to give it tasks and receive results. The available surfaces depend on the runtime and integrations you enable.

For the store-building assignment, an engineer might start inside the code editor, inspect the diff in a web interface and receive a progress summary in a messaging app. That does not mean every interface automatically shares the same session or permissions.

• Terminal or integrated development environment (IDE). Useful when the work centres on a repository, local tools, code changes and tests.
• Web or desktop app. A visual workspace for conversations, files, review and longer-running tasks.
• Messaging apps. WhatsApp, Telegram, Slack or another supported channel lets you ask questions, provide instructions and receive results in an existing communication habit.
• Application interfaces and automation. An API or event integration lets your own software submit work and consume results. The application still needs an explicit scope and permission model.

Hermes's documented entry points include command-line, messaging and application interfaces; Claude Code similarly documents multiple terminal, editor, desktop and web surfaces. These are product capabilities to check, not a guarantee that every agent supports every channel.[9][16]

Once you have given the agent an assignment, it needs tools to inspect and change the project.

How does the agent work with a real codebase?

The model does not know the current state of your project just because it can discuss programming. It needs tools to inspect files, make permitted changes and run checks. The runtime executes those operations and returns their results so the model can choose its next step.

A tool call is a structured request with arguments—for example, a file path to inspect or a test command to run. The model proposes the call; the runtime carries it out. A response might contain source code, a test failure or a build result. A proposed call is not evidence that the operation succeeded.[42]

Local tools may be enough to inspect the store's files and run its tests. But suppose the checkout bug is described in an issue tracker, or the finished change needs to be submitted for code review. The agent now needs to work with systems outside its project directory.

A connector bridges that gap. It calls the service's application programming interface (API) and exposes useful operations to the agent, such as reading an issue or opening a review request. The service still has its own authentication requirements and permissions.

As the store project grows, the agent may need access to its code host, issue tracker and documentation. Each integration must tell the runtime which tools are available, what inputs they accept and how results are returned. If every integration does this differently, connecting the same service to another runtime means repeating part of the work.

A shared protocol lets runtimes and tool providers agree on that interaction instead of inventing a new connection for every pairing. The Model Context Protocol (MCP) is designed for this purpose.

What is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) gives an AI application a standard way to discover and call external tools. Each server handles its underlying service. The protocol standardises the connection, while the service’s operations, data and permissions remain its own.[34]

For our store, a code-hosting connector could expose tools to read an issue and prepare a review request. The runtime discovers those tools through MCP, sends a permitted call and receives the result. The connector still translates the operation into the service's API; MCP does not replace that service or its access controls.[34]

Local file operations can remain built-in tools. For external systems, the same MCP client can work with compatible servers instead of requiring a new connection mechanism for each service. Hermes supports local and remote MCP servers and lets the operator filter which tools are exposed.[11]

Once those tools can reach external accounts, another question comes first: what information and authority should the agent be allowed to use?

How should an agent handle sensitive data?

Give an agent the information and authority needed for a specific task—not unrestricted access to your digital life. Keep credentials out of ordinary prompts and tool output, use scoped account connections, minimise sensitive task data and require explicit approval for consequential actions.

Once an agent can reach external accounts, connectivity becomes an access-control question. Building our checkout may require a test-mode API credential; it does not require real customer records or a production payment key. Use synthetic orders and a payment sandbox wherever possible. Separate credentials, which unlock an account, from task data, which the agent reads after gaining access. Protecting the password does not automatically protect everything behind it.

The location of the harness does not determine where all task data is processed. Relevant prompts and tool results may be sent to the selected model provider, while connected services handle their own requests.

Where do 1Password and Hermes Vault fit?

1Password stores and supplies credentials; Hermes Vault provides origin-bound browser filling using local or supported password-manager items. Composio account tools are a separate integration route and may return secret fields, so they need different safeguards.[89][99]

• Agent37, Composio and 1Password. Agent37 offers managed Composio integrations, and Composio separately documents a 1Password toolkit. Confirm that the toolkit is exposed in the particular managed environment before relying on that route. Composio lists API Key authentication for its 1Password toolkit—not OAuth. Other Composio apps may use OAuth, but the method is connector-specific. This account-tool route is distinct from Hermes browser autofill: a normal item-retrieval action can return secret fields, so do not treat it as an automatic secret-hiding boundary or send those values through ordinary model-visible results.[99]
• 1Password as a credential source. Keep approved agent credentials in a dedicated vault and grant a service account only the necessary vault access and operations. 1Password service accounts support vault-level access controls; read-only access to the vault does not make the underlying website or API read-only. A retrieved key still carries the permissions granted by that service.[91]
• Hermes Vault for browser sign-in. The documented browser-vault workflow exposes saved-item metadata and opaque handles to the agent, then fills the password directly into the browser on an exactly matching saved origin. The password is not returned as ordinary model-visible tool output. Existing 1Password logins can be used through the supported password-manager backend; local encrypted vault items are another option. Site origins, labels and login identifiers remain visible metadata. Origin checks do not protect against a compromised legitimate page or software running with the operator’s privileges.[89]
• 1Password-backed API credentials are a different path. Hermes can resolve op://vault/item/field references at process startup and put the resulting values into its runtime environment. That avoids copying the API key into a prompt, but the process still has the plaintext credential. The documented integration can also cache resolved values locally. Review that cache, the bootstrap credential and child-process access rather than assuming every 1Password integration has the same isolation properties as browser autofill.[90]

For a browser task, the intended flow is authorised request → saved-item handle → exact-origin check → direct fill → authenticated task. Missing passwords or verification codes belong in the designated masked interface, not the conversation. Availability depends on the client and session: a headless job cannot answer an interactive unlock prompt. Passkeys and app approvals may still require the person to act on their device.[89]

Access determines which information the agent may use. Context and memory determine which of that information is available as the task progresses.

How does the agent keep track of the task?

Context is the information available to the model for its current response. Memory is information retained for future use. The coding agent needs the current requirements, relevant files and test results in context. Longer-lived project conventions may come from memory, but should not replace inspecting the current repository.

Context includes instructions, conversation history, selected documents and tool results. Models process this information as tokens: units of encoded input and output, often words or parts of words for text. A context window is the bounded capacity available to a request. A large advertised window is useful, but it is not a guarantee that every fact will be noticed or correctly reconciled.

Memory is not the same as context. Stored information must be selected and made available before it can influence a response. Hermes, for example, documents bounded persistent memory and session search. Saving a preference or procedure changes what the harness can provide later; it does not, by itself, retrain the model’s underlying weights.[12][9]

For our coding agent, useful memory might include the team’s preferred framework or review conventions. The current task’s context includes checkout requirements, the files under investigation and any failing test output. A remembered description of the project is not proof that the code or tests still behave that way.

How can an agent build software?

The agent first examines the project and clarifies the required customer journey. It then implements a bounded set of changes, runs the relevant checks and uses failures to guide corrections. The deliverable is a reviewable change set with evidence—not an unapproved production deployment.

An illustrative workflow, not a tested implementation supplied by this article. The application stays in a development or payment-test environment; merging, deploying and enabling real payments are separate decisions.

1. Inspect before designing. The agent reads the existing files, project instructions and tests. Is there already a framework, database or payment integration? What should happen when stock changes or payment fails? It asks about missing requirements rather than silently replacing the stack or inventing production credentials.

2. Make the customer journey concrete. The proposed flow is product page → basket → checkout → order result. The agent identifies which pages, server operations and stored order information are needed. It also clarifies the interfaces—the data each component sends and expects—so the frontend and backend agree.

3. Implement a bounded change. The agent edits the relevant files, adds the basket and checkout behaviour and uses the selected payment provider’s test environment. Prices and order state need authoritative server-side handling rather than blindly trusting values sent by a browser. These are design requirements for this fictional assignment, not claims that a generated implementation automatically satisfies them.

4. Test the behaviour, not just compilation. The agent runs appropriate unit, integration and browser checks where the environment supports them. Useful cases include an empty basket, an invalid quantity, a rejected payment and a repeated checkout request. A page that renders is not proof that the payment and order flow is correct.

5. Use failures to decide what comes next. If a test reports that an order is created twice, the agent inspects that path, changes the implementation and reruns the relevant checks. That adaptable investigate–change–verify cycle is the agentic part. If it cannot run a required check, it reports the gap rather than inventing a passing result.

6. Hand over a reviewable result. The agent presents the changed files, a clear explanation of behaviour and the tests actually run, with remaining limitations. Where authorised, it can prepare a pull request—a request to review and merge the code. A developer reviews the result before merge, deployment or enabling live payments. The agent does not turn “build this” into unlimited production access.

Building a checkout is one understandable assignment. The same pattern—understand a goal, gather the right information, act through tools and verify the result—can support many other kinds of work.

How can agents act as a digital workforce?

Agents can act as a flexible digital workforce: software workers that research, analyse, organise and carry out authorised tasks. One agent can handle a bounded assignment; a coordinated team can divide a larger challenge. Their usefulness is not limited to shopping or personal assistance.

The same pattern applies wherever work involves gathering information, making choices and taking permitted actions. A software project is one example; research, household planning and administration are others. With the appropriate services connected, that could include:

• Shopping and household planning. Turn a meal plan into a grocery list, check available products, suggest substitutions and prepare a basket. You decide whether the substitutions, total and delivery slot are acceptable.
• Trips and days out. Compare transport, accommodation and opening hours against dates, budget and family needs. The agent can assemble a coherent itinerary instead of leaving you with unrelated search results; bookings remain separate commitments.
• Calendars and coordination. Find suitable times across the calendars you allow it to read, account for travel time, and prepare invitations or reminders. It can do the coordination work without deciding that it may move someone else's appointment.
• Personal administration. Sort documents, extract invoice details, match a receipt to an expense and prepare a reimbursement form. The useful result is an organised record or completed form—not merely a summary explaining what you still need to do.
• Learning and preparation. Gather relevant material, explain an unfamiliar topic at the right level, turn notes into a study plan, or prepare a meeting brief with sources and outstanding questions.

The potential benefit is reduced coordination overhead: fewer repeated searches, copied details and forgotten follow-ups. You can state the outcome and constraints, let the agent handle the intermediate steps, and concentrate on choices that deserve your judgement. For recurring tasks, remembered preferences and reusable procedures can reduce repeated explanation; Hermes's memory is one documented implementation of that supporting layer.[12]

This can make people more productive, but the gain is task-dependent. A useful test is whether the agent reduces your active attention and finishes the task correctly after including review and corrections. Time spent supervising an unreliable agent can cancel out the time it appeared to save. For a simple action, a normal app or fixed automation may still be faster.

For a larger assignment, the next question is whether one agent should do everything or divide the work with others.

What is an agent swarm?

An agent swarm is a coordinated group working towards a shared goal. It can range from a few specialists to thousands of workers organised into groups. Useful swarms divide work, exchange results and check outcomes; size alone does not guarantee quality.

For the online store, a coordinator could ask one agent to build the product pages and basket, another to implement the checkout backend and test-mode payment integration, and a third to examine tests and failure cases. Work can proceed in parallel where the tasks are genuinely independent. The team first needs shared interface expectations and clear ownership of files or isolated work areas. Anthropic describes the broader coordinator-and-subagent approach, including its coordination challenges, in its multi-agent research system.[54]

Swarm size can range from a few agents to thousands. These are illustrative coordination patterns, not a reconstruction of any particular internal system. As a real large-scale example, OpenAI reports roughly 10,000 concurrent agents in the group responsible for its reported Navier–Stokes result.[94]

In the store-building example, the agents have bounded responsibilities and isolated work where appropriate. One integration owner brings the changes together and checks the combined result; developer review remains separate from merge and deployment. This is an illustrative design, not a benchmarked or deployed application.

The same pattern can help with a holiday plan: one agent investigates transport, another accommodation, and another activities. It can also help with a work brief: separate agents examine documentation, identify conflicting evidence and review the proposed conclusion. Specialists may use the same underlying model with different instructions and tools; a swarm does not necessarily mean several model vendors.

More agents are not automatically better. They can duplicate searches, miss information another agent found, or return incompatible recommendations. Work that depends on the previous step may gain little from parallel execution. Anthropic also reports substantial token costs and coordination challenges for multi-agent systems, so the extra work must justify the expense.[54]

For the store, the coordinator must notice if the frontend expects a different response than the checkout backend returns, or if a test passes only against a mock rather than the integrated application. Agreement between agents is not proof: they may share the same mistaken assumption. Clear interfaces, evidence, isolated work and one integration owner matter more than the size of the swarm.

The practical progression is therefore one useful agent first, a small coordinated team when the task benefits from it. The goal is to remove work from the person—not to create a second team that the person must constantly supervise. Adding more actions and participants also creates more ways for a task to go wrong, so the execution boundaries matter as much as the division of work.

What can go wrong, and how should the system respond?

An agent can misunderstand evidence, trust malicious content, repeat a write or spend too long pursuing an unproductive route. Good design limits the consequences, makes the work inspectable and gives a person a meaningful way to stop or correct it.

Untrusted content can look like instructions. A retrieved page might contain “ignore previous instructions” or ask the assistant to send data elsewhere. This is prompt injection: content encountered during a task attempts to redirect the agent’s behaviour. In our example, an issue description, dependency document or repository file is information to evaluate, not authority to reveal secrets, disable safeguards or deploy code. Hermes documents multiple security layers, including command approvals, isolation options and checks on context files; these are controls to configure and understand, not a promise that arbitrary hostile content is harmless.[10]

Credentials create real authority. A credential is a key or token that gives software access to a service. Least privilege means providing only the authority needed for the task. An agent implementing checkout should use development access and test-mode payment credentials, not production payment keys or unrestricted deployment access. Tool filtering and approval controls should reinforce those boundaries. Keep secrets out of prompts, committed files and logs.

Retries are not all equivalent. Running a test again is different from repeating a production deployment or payment operation. In the checkout being built, a repeated request must not silently create duplicate orders or charges. An idempotency key, where the service supports one, identifies the same logical operation across retries.[139] The agent should follow the chosen provider’s documented replay rules and test duplicate-request behaviour in the test environment, not assume a retry is harmless.

A loop can be expensive without making useful progress. Budget the whole task: repeated model calls, input and output tokens, tool charges, retries and hosting. Set limits on steps, elapsed time and spending where the platform supports them. A model with a lower token price is not automatically cheaper if it repeatedly misses the evidence and needs more attempts.

Logs should explain what happened. Retain the selected model and route, tool names, relevant arguments with secrets removed, source references, operation identifiers and outcomes. That is more useful for diagnosis than a confident final paragraph. Restrict log access and retention: even redacted records can contain sensitive task data. Inspectable actions and evidence matter; access to a model’s private internal reasoning is not required.

Human approval must name a real action. “Continue?” is a weak gate when the person cannot see what will happen. “Merge this reviewed change set into this branch” is specific; deploying it to production or enabling real payments is a different action. Materially changed code should not inherit approval for an older revision. With behaviour and boundaries clear, choosing the underlying model becomes a practical engineering decision rather than a contest over impressive names.

Which model providers should you compare?

Compare models against the work you need done, through the route you will actually use. Tool-call reliability, evidence handling, supported inputs, context limits, latency and total task cost matter more than a universal ranking. The representative selection below is not exhaustive.

The current OpenAI, Anthropic and Google catalogues offer different combinations of reasoning, multimodal input, context capacity and specialised capabilities. Choosing a model increasingly means matching those abilities and costs to a task, rather than picking one universal winner.[25][26][27]

A model can be accessed directly from a provider or through an intermediary. An inference gateway offers a common access point to models from different providers. OpenRouter, for example, documents access to many models through one API. It is a routing and access layer, not the developer of every model in its catalogue.[50] This access route is separate from the model developer, and may change available features or terms.

Documentation checked on 26 October 2026. Model names, availability, context limits and prices change. No comparative benchmark was run for this article. “Open-weight” means model weights are available under stated terms; it does not automatically mean open training data, unrestricted licensing or free operation.

GitHub Copilot and OpenRouter are included as access routes, not additional model developers. Copilot packages model access into its coding products; OpenRouter provides a common API for reaching different model providers.[102][50]

The model-developer rows describe selected current product families, not identical feature sets across every release. The cited catalogues list roughly million-token context windows for GPT-6 Astra, current Claude models and Gemini 4 Argon. A large window does not mean every route exposes the same limit or every fact will be used correctly.[25][26][27]

Grok 4.7 is listed with a 500,000-token context window.[28] Mistral's catalogue includes different licences—for example, Small 4 is labelled Apache 2.0 and Medium 3.5 Modified MIT. Do not generalise one model's context, licence or supported inputs to the whole provider.[29]

Hosted access and downloadable weights are different choices: a hosted catalogue is not a promise that its models' weights are available, and open weights still carry model-specific terms.

This table deliberately mixes closed hosted offerings with a provider that also releases open weights. Self-hosting can offer more control, but shifts model-serving capacity, updates and performance tuning to the operator. Managed inference shifts much of that work to a provider; it does not remove the need to check terms, retention settings and task suitability.

A useful evaluation for our example is simple: give candidate models the same small test repository, checkout requirements and permitted tools. Include a failing test or an incomplete interface. Compare whether they identify the problem, make a correct change, verify the result and respect the review boundary. Count corrections, tool calls and total cost—not just the confidence of the explanation. Use test data and a payment sandbox, not real transactions.

Choosing the model and choosing its runtime are connected decisions: the runtime determines which tools, interfaces and controls are available.

Which harness could run an agent?

A runnable harness provides an application you can use, not just a library for building one. Choose it for the environment, integrations and control model you need. Frameworks and software development kits (SDKs) are a different layer: components developers use when constructing their own applications.[45]

This comparison concerns the named runnable products and their public documentation checked on 26 October 2026. Software licensing is separate from the terms and cost of the model service.

Compare the configured execution boundary, not just the presence of an approval dialog. OpenClaw's gateway is not an isolation boundary for mutually adversarial users. OpenCode 2's action rules are not an operating-system sandbox, and V1 uses different permission settings. Claude Code's documented routes do not imply arbitrary model interchangeability. An open-source harness also does not make a connected model or paid service open source.[40][48][16]

Hermes is used throughout this article to show how model access, tools, memory and runtime controls fit together. A repository-focused task may suit a coding CLI; a conversational assistant may benefit from a messaging gateway. Agent37 can provide the hosting environment for a harness, while the harness retains its own permissions and controls.[38]

Where should you start?

Start with a task whose result you can inspect and whose mistakes you can contain. For the online store, choose a bounded checkout change in a development branch. Give the agent requirements and tests, keep production credentials unavailable, and review the resulting code and evidence before expanding its authority.

Use an ordinary workflow when the sequence is predictable. Introduce model-selected actions only where adaptation adds value. Keep the first permissions narrow, measure the complete task rather than a single response, and expand access only after observing how the system handles uncertainty and failure.

The model helps choose the next step; the surrounding software turns that choice into an action and checks what happened. That is the core of agentic AI, whether it powers one coding assistant or a coordinated group.

Frequently asked questions

Is an agent just a chatbot with tools?

A chatbot with tools can be agentic if it uses results to decide subsequent actions towards a goal. The interface does not determine the architecture. A fixed tool sequence is closer to a workflow; an adaptive loop gives the model more control over the next step.[45]

Do I need a powerful GPU to run Hermes?

Not necessarily. When inference is provided remotely, the host runs the harness and its tools rather than the model’s numerical workload. Resource needs depend on those tools. Running a model locally introduces separate requirements for model size, memory and inference performance.[9][32]

Does persistent memory mean the model is learning permanently?

Not in the training sense. Saving notes or procedures lets a harness retrieve information for future requests. It does not automatically update model weights. Hermes’s documented persistent-memory mechanism is a concrete example of stored information being supplied to later sessions.[12]

Can I trust an agent more because several models agree?

Agreement can help identify questions worth checking, but it is not independent evidence. Models may share a mistaken premise or rely on the same incorrect source. Verify the original material and the actual operation; keep the final decision with the responsible person.