LinkedIn describes evolution of AI agents: from chains to executable code

InfoQ published an article this Monday, October 26, that organizes into three generations the way engineering teams have been building AI agents: chains, graphs, and, more recently, code-based harnesses. The piece is authored by Karthik Ramgopal and is part of the outlet's "Agentic AI Architecture" series, reviewed by Rafał Gancarz. The central focus: moving away from probabilistic "best effort" toward systems with traditional engineering guarantees, using real LinkedIn cases as illustration.

From fragile chains to graphs with explicit control

The first generation described in the article is chains: linear sequences of prompts in which the output of one step feeds the next. According to the author, one of LinkedIn's first generative agents used a fixed three-step chain built with the LangChain framework, divided into routing (classifying the question and choosing the right specialist), retrieval (fetching data via Bing or internal LinkedIn APIs), and generation (synthesizing the final answer).

This architecture is quick to build but fragile: an error in the routing step propagates with no detection or recovery mechanism whatsoever. The article describes this as the "best-effort" pattern of early agentic products, in which the first 80% of the experience came together quickly, but closing out the last 20% required extensive rounds of evaluation and prompt tuning.

The response to this fragility was graphs: nodes represent tasks (LLM calls, tool invocation, validation) and edges control flow, enabling conditional branching, parallelism, and retries. At LinkedIn, this layer was implemented on top of LangGraph and brought four capabilities the article lists as central:

• Conditional execution, with routing and re-routing based on intermediate results;
• Retries and fallbacks for graceful failure recovery;
• Structured state management beyond loose text;
• Explicit validation (schema, business rules, or secondary models) before trusting the LLM's output.

This structure also made room for multi-agent systems with a higher-level orchestrator, requiring asynchronous agent-to-agent communication protocols such as A2A and ACP (which later merged into A2A). At LinkedIn, this orchestration was built by reusing the platform's existing messaging system, with guaranteed FIFO-order delivery. The article cites Hiring Assistant, LinkedIn's first AI agent aimed at recruiters, as a product born from this graph architecture.

Code as the centerpiece: sandbox, tests, and validation

The third generation treats code, not prompts, as the agent's primary reasoning medium. Instead of asking the model to "think out loud" about a complex problem, the harness generates code, runs it in an isolated sandbox, and refines the result in a loop until it passes the correctness criteria.

The practical difference, according to the article, is that LLM-generated text is probabilistic and, before validation, unreliable; code, on the other hand, is deterministic: it either compiles and delivers the correct result, or it fails explicitly. This binary failure/success cycle is what, in the author's view, most dramatically improves the system's reliability.

The article describes four components as mandatory in this architecture:

A production case: LinkedIn's internal analytics agent

LinkedIn uses this pattern in an internal tool that lets developers, product managers, data scientists, and even business operations staff ask analytical questions in natural language and receive answers based on aggregated platform data. The agent translates the question into a combination of declarative SQL and imperative Python, runs it against a data sample, validates the output against strict privacy and governance constraints, and iterates in a loop until it meets all criteria.

According to the article, the code-based approach reduced time to launch compared with manually building prompts, tools, and flow graphs, while also making the system more auditable and reproducible, since every run leaves a trail of code and tests that can be inspected later.

What the author recommends as minimum practice

Regardless of the architecture's stage, the article lists four principles as what separates robust systems from fragile ones:

1. Treat the LLM's output as untrusted input, applying schema checks, business rules, or secondary models before any downstream decision;
2. Decouple planning from execution, letting the model propose a plan but executing it within a controlled software framework;
3. Invest in observability, capturing state at every step, execution traces, and validation results, with sensitive data masking;
4. Build for continuous improvement, with feedback loops that capture failures and feed the evolution of the system's prompts, policy, and memory.

Which abstraction to choose, and what it changes for developers in Brazil

The article is direct about when to use each layer. Chains are enough for narrow, linear tasks, such as drafting a support reply, summarizing a document, or extracting structured data from predictable inputs, because they minimize model calls and orchestration overhead. Graphs come into play when the flow requires conditional branching, retries, or tool invocation, such as multi-step support resolution or corporate IT automation. Code harnesses are justified where precision and verification are critical, such as software engineering agents, financial analysis, or legal document validation, areas where the output can be tested, compiled, or formally verified.

The fundamental principle is simple: Use the least complex system that reliably solves the problem.

Karthik Ramgopal, author of the article and AI engineer at LinkedIn

For those building AI agents here, the practical takeaway is direct: the temptation to jump straight to graph architectures or code harnesses, because they're the topic of the moment, costs money and latency without necessarily improving the business outcome. The article reinforces that strong engineering organizations don't win by maximizing architectural sophistication, they win by optimizing capability per dollar spent. Before designing a graph in LangGraph or a code execution sandbox, it's worth measuring whether the problem really demands more than a linear chain of prompts validated with schema checks on the output.

It also changes the role of those who build these systems. The piece describes a transition from "Prompt Designer" to "System Architect": in early chains, the differentiator was the crafted skill of writing the right prompt; in graphs and code harnesses, the focus shifts to real software engineering, designing execution flow, managing state and dependencies, and building validation and recovery mechanisms. It's this shift, more than any specific framework, that the InfoQ article documents as the structural change in how AI is built in production.