DEV Community

code performance
code performance

Posted on

The 30-Year-Old Blueprint for Modern AI Agents

#ai #agents #1996 #agentskills

In 1996, computer scientist Marc Belgrave penned a vision for software agents in a book titled BOTS and Other Internet Beasties. Decades before OpenAI, AutoGen, or the Model Context Protocol (MCP), researchers were already grappling with a foundational question: How do we build autonomous software that acts on a user's behalf across a network?

Flipping through those early pages today feels like reading a blueprint for 2020s AI agent frameworks. The key operational problems modern AI developers face—tool discovery, rate limits, identity, security, and safety guardrails—were fully mapped out 30 years ago.

We didn't invent the architectural problems of agents in the LLM era. We simply swapped out the engine.

When we build AI agents today using frameworks like LangGraph, AutoGen, or CrewAI, it feels like we are blazing a trail through entirely new territory. But opening Marc Belgrave’s 1996 text, BOTS and Other Internet Beasties, reveals a surprising truth: the fundamental architecture of autonomous software was mapped out three decades ago.

In Chapter 1, Belgrave outlined the core challenges of distributed software agents. Reading those early pages alongside today’s AI stack shows that while our technology has changed dramatically, the system-level problems of agent governance, communication, and goal-oriented execution have remained identical.

       1996 ARCHITECTURE                      2020s AI ARCHITECTURE
┌───────────────────────────────┐      ┌───────────────────────────────┐
│     Agent Specification       │      │   Natural Language / Prompt   │
│  (Goal / Pseudo-Language)     │      │   (System Roles, Declarative) │
└──────────────┬────────────────┘      └──────────────┬────────────────┘
               │                                      │
┌──────────────▼────────────────┐      ┌──────────────▼────────────────┐
│   KQML Message Layer          │      │  JSON / Model Context Proto   │
│ (Performatives: tell/ask/sub) │      │  (Tool Calls, Schemas, RPC)   │
└──────────────┬────────────────┘      └──────────────┬────────────────┘
               │                                      │
┌──────────────▼────────────────┐      ┌──────────────▼────────────────┐
│      Deterministic Engine     │      │     Probabilistic Engine      │
│   (Expert Systems, Logic)     │      │      (LLM / Transformer)      │
└──────────────┬────────────────┘      └──────────────┬────────────────┘
               │                                      │
┌──────────────▼────────────────┐      ┌──────────────▼────────────────┐
│         Mobile Code           │      │    API & Cloud Execution      │
│  (Telescript / Java Applets)  │      │   (REST APIs, Microservices)  │
└───────────────────────────────┘      └───────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

1. Goal-Oriented Abstraction: Moving Beyond "Fancy Scripts"

In 1996, Belgrave cautioned that agent systems were being held back because developers kept thinking in procedural terms:

"The greatest promise of the agent concept is in giving users the power to think of what they want to accomplish instead of how to accomplish it. The greatest danger facing the field is the tendency for developers to approach the building of agent systems solely with the techniques and preconceptions of the present age."

The 1996 Dilemma

Early developers tried to build "agents" by forcing non-technical users to write procedural scripts (e.g., using Safe-Tcl or General Magic’s Telescript). Belgrave argued that this approach reduced agents to rigid, step-by-step algorithms with no room to adapt. He envisioned an Agent Specification Language (ASL)—a high-level interface where a user declared an outcome in pseudo-English, leaving the system to determine the steps.

The Modern Realization

What was theoretical in 1996 is now standard practice. In LLM-based agent development, natural language serves as the specification language. System prompts, task descriptions, and tool definitions describe what needs to be achieved, while the LLM determines the execution path dynamically.

2. Communication Protocols: KQML vs. Model Context Protocol (MCP)

To collaborate, agents must share a common communication layer. In 1996, the Knowledge Query and Manipulation Language (KQML) was the primary protocol attempt.

                     1996 KQML MESSAGE STRUCTURE
┌───────────────────────────────────────────────────────────────────┐
│ COMMUNICATION LAYER: :sender AgentA :receiver HostB               │
├───────────────────────────────────────────────────────────────────┤
│ MESSAGE (PERFORMATIVE) LAYER: :performative ask-one :ontology Finance│
├───────────────────────────────────────────────────────────────────┤
│ CONTENT LAYER: (stock-price "AAPL")                               │
└───────────────────────────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Belgrave detailed how KQML separated a message into three distinct layers:

  1. Communication Layer: Sender/receiver metadata and network routing parameters.
  2. Message Layer (Performatives): The verb defining intent (e.g., ask-one, tell, subscribe, reply).
  3. Content Layer: The raw data or logic payload (often encoded in KIF or Prolog).

The Modern Equivalent

Today's open standards mirror this exact three-layer design:

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "get_stock_price",
    "arguments": { "ticker": "AAPL" }
  }
}
Enter fullscreen mode Exit fullscreen mode

Standard protocols wrap communication into:

  • Transport: WebSockets, Server-Sent Events (SSE), or HTTP.
  • Performative Intent: JSON-RPC methods (tools/call, prompts/get, resources/read).
  • Payload Content: Structured JSON arguments validated against an JSON Schema.

Decoupling the intent of a message from its content remains essential for safe inter-agent communication.

3. Governance: Passports, Lifespans, and Safety

As software autonomy increases, system safety becomes critical. The 1996 text highlighted security risks that remain relevant today:

  • "How do I know that my purchasing agent will not run amok and overdraw my credit limit?"
  • "How can I be sure that my mail agent will not forward inappropriate correspondence?"

The 1996 Solution: Cryptographic Passports

Belgrave called for every agent to carry a tamper-proof passport containing:

  • Origin & Identity: Verification of the user or system responsible for launching the agent.
  • Lifespan & Expiry: Hard time limits and execution-step quotas.
  • Scope Limits: Restricted access permissions for host system capabilities.

The Modern Solution: Alignment & Execution Guardrails

Modern AI engineering relies on a similar set of protective controls:

  • Human-in-the-Loop (HITL): Requiring user approval before executing financial, destructive, or external communications.
  • Budget & Token Limits: max_steps loops and rate limits to prevent endless execution.
  • Sandboxed Runtime Execution: Executing generated code inside isolated containers (e.g., Docker, E2B micro-VMs).
  • Output Validation: Enforcing structured JSON outputs to verify that an agent's response conforms to strict business logic before execution.

4. The Architectural Split: Why "Mobile Code" Died

While Belgrave correctly anticipated governance, protocol structures, and goal abstraction, the 1996 vision missed the mark on the underlying execution model.

    1996 VISION: MOBILE CODE             MODERN REALITY: API ORCHESTRATION
┌───────────────────────────────┐      ┌───────────────────────────────┐
│     Agent Serialization       │      │   Centralized LLM Runtime     │
│  (Code + State moves over IP) │      │  (Agent stays in the Cloud)   │
└──────────────┬────────────────┘      └──────────────┬────────────────┘
               │                                      │
               ▼                                      ▼
┌───────────────────────────────┐      ┌───────────────────────────────┐
│    Remote "Host Agency"       │      │   Remote REST API / Service   │
│  (Executes incoming payload)  │      │ (Returns data to central LLM) │
└───────────────────────────────┘      └───────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode

The 1996 Bet on Mobile Code

In the mid-1990s, the dominant paradigm was remote programming. Technologies like General Magic’s Telescript and early Java applets assumed that shipping an agent's code across the network to execute locally on a remote server was faster and more efficient than pulling raw data back over slow dial-up connections.

Why Cloud APIs Won

As web infrastructure matured, the industry shifted toward centralized API orchestration:

  1. Security Constraints: Opening servers to untrusted, incoming executable code created significant security vulnerabilities.
  2. REST & Microservices: Standardization around HTTP/REST APIs made querying remote data simple and reliable.
  3. Compute Asymmetry: Modern AI agents require vast GPU resources to generate decisions. The agent's reasoning engine stays in the cloud, issuing structured tool calls to external services over standard Web APIs.

Key Takeaways for Modern AI Engineers

The evolution of agent architecture highlights a clear pattern: cognitive engines change, but distributed systems problems remain consistent.

  1. System boundaries matter as much as prompt engineering: Prompting alone cannot solve security, rate limits, or tool routing. Building production AI agents requires robust software architecture.
  2. Standardize tool definitions early: Separating intent, data payloads, and transport protocols—just as KQML attempted in 1996—is essential for building scalable, maintainable multi-agent systems.
  3. Build safety into the architecture: Autonomous software requires explicit boundaries, execution timeouts, budget caps, and identity verification before it can safely execute actions on behalf of users.

Top comments (0)