Back to the Future: What General Magic’s 1994 Telescript Can Teach Us About Agentic AI Safety Today
Why today's “autonomous” AI agents are less safe than the ones we built in 1994
The current industry “fizz” (bubblespeak for buzz) is about “agentic AI”: systems that can act autonomously and interact with the real world, booking travel, managing portfolios, and navigating supply chains, all based on user-set constraints (at least we hope so, for that last part).
The AI industry’s pitch is familiar: Trust us. We’ll build responsibly. Safety is our top priority.
We’ve heard this before—from media companies, from platforms, from every institution that inherited power without inheriting restraint. Incentives quietly redefine what safety is allowed to cost.
So when LLM companies promise “responsible” agentic AI, we ask: what does that actually look like? Not as aspiration. As architecture.
Thirty years ago, General Magic’s Telescript established a foundation for autonomous agents. The vision behind it sounds like today's promises of Agentic AI but in fact was actually enabled by the technology from the outset. Telescript didn't ask users to just trust it. Instead, it built deterministic safety into the system itself—Permits that limited resource consumption, Authorities that enforced accountability, an Engine that prevented agents from touching host resources directly.
The current “Agentic AI” movement has almost entirely neglected these questions. It’s not that the technology can’t be built safely. It’s that building it safely requires constraints that conflict with growth. Some AI companies are even asking governments to regulate them—a move that sounds responsible but often shapes regulation to entrench incumbents and foreclose competition. We’ll explore that dynamic in future posts.
Here’s what structural safety for autonomous agents actually required—and what we’re missing now.
The “Chris” Scenario: A 1994 Vision of Autonomous Travel
The "dream" of the autonomous travel agent currently being chased by generative AI startups was the foundational use case for General Magic’s Telescript network. In our February 1995 IPO prospectus, we described the first user scenario for Telescript: “Chris," a user needing a business trip to Boston.
The 1994 Step-by-Step Autonomy:
Creation: Chris uses a Magic Cap device device to create an agent with specific constraints: travel dates, a Visa card number, and airline preferences.
Migration: The agent executes a "Go" instruction to travel to an airline "Place" (a stationary service) within the electronic marketplace. Think of it as a storefront airline office.
Interaction: The mobile agent meets the stationary agent residing at the Airline Place. They interact locally via a “Meet” instruction, which allows the mobile agent to book the flight and receive a confirmation number.
Persistence and Cost: Before returning, the agent creates a second, low-resource agent of Chris’s authority to “sleep” in the network. The Airline Place might charge Chris a fee for this agent’s “room and board.” Shortly before the date of travel, this agent begins to arise hourly to monitor for delays.
Completion: If a delay occurs, the persistent agent executes a “Go” back to Chris’s communicator—even if the device had been turned off for days—to deliver the notification.
This wasn't theoretical. AT&T, a charter member of the General Magic Alliance of multinational consumer electronics and telecom companies, launched the first Telescript-enabled network, PersonaLink, with plans to interoperate with France Telecom, NTT, and Cable & Wireless, other Alliance members. We envisioned an international system of interconnected, Telescript-enabled devices and networks spawning legions of agents that would travel the world on their users' behalf, interact with sources of goods, information and services and with each other, and free their creators from drudgery.
In fact, General Magic and AT&T are credited with coining the term,“cloud computing.”
As the story of General Magic’s failure goes, Magic Cap devices didn’t sell, other device makers didn’t adopt Telescript (which was hardware-independent), and AT&T shut down PersonaLink. The full story of why—and what we learned—is one we’ll be exploring in upcoming posts. For now, what matters is what we got right about safety. Can we learn from it?
The Architecture of Mobility: Remote Programming (RP) vs. Remote Procedure Calls (RPC)
Telescript wasn’t based on generative AI, but its idea of self-executing intelligent agents foreshadowed what is taking shape around us today …as did the rest of General Magic’s original vision of anywhere, anytime communication and hand-held access to a global electronic marketplace. One crucial difference—Magic was alert to the possibility of bad actors and rogue agents, and created a robust security architecture to prevent their development or hosting.
That awareness, and our attempt to deal with it, is what’s lacking in the current frenzy of AI platforms’ rush to outdesign and outperform their competitors. “Too much security and attention to safety” would purportedly stifle innovation--and the tech broliarchy is doing what it can to neuter both government regulation and industry caution. That shortsightedness is one mistake we didn’t make in Telescript.
To understand why Telescript agents could operate safely and autonomously, you need to grasp the fundamental architectural shift from Remote Procedure Calling (RPC) to Remote Programming (RP). Without getting too geeky, we can turn to how Jim White, Telescript’s architect, characterized the status quo as “shouting commands across a network.” In contrast, Telescript viewed the network itself as a platform.
The tactical advantage of RP was the “Go” instruction. In Telescript, networking was reduced to a single program instruction. When an agent executed “Go,” the Telescript Engine performed a feat of serialization: it packaged the agent’s code, its data, and its exact execution state—even the program counter. The agent would then “vanish” from the client and “materialize” at the destination, resuming execution at the very next instruction. This wasn’t just downloading code; it was migrating a live process.
The Safety Gap: What General Magic Built That Today’s AI Agents Lack
The strategic failure of the modern "Agentic" movement is its reliance on "chatty," high-latency protocols while ignoring the robust, deterministic "rules of the road" that Jim White and his team codified in the mid-90s.
AUTONOMY AND DISCONNECTED OPERATION
The definition of “autonomy” has regressed in the present age of agentic services.
Modern AI Autonomy: Relies on non-deterministic reasoning. It relies on a high-latency loop of API calls. If the user’s phone loses signal, the “agent” usually fails because the intelligence is tethered to a “chatty” client-server connection.
Legacy (Telescript) Autonomy: Focused on disconnected operation. An agent was a delegate. Once sent, the user’s device could be powered down or go offline. The agent performed its work independently on the server-side platform, reducing the network to a simple transport medium.
DETERMINISTIC SECURITY: PERMITS AND AUTHORITIES
Today’s AI agents operate in a "Wild West" of prompt injections and unchecked API permissions. Telescript, by contrast, was a masterpiece of deterministic security.
Permits — Telescript used Permits to provide a strict mechanism for limiting resource consumption. Every agent was governed by two types of limits:
Quantitative Limits: These included maximum lifetime (age in seconds), maximum size (bytes), and Teleclicks (a budget for computation). If an agent attempted to exceed these, the engine destroyed the agent immediately to protect host resources.
Qualitative Limits: These were rights to execute specific instructions, such as the ability to create new agents or perform a “Go.” If an agent lacked the permit for an instruction, the engine simply prevented the execution without destroying the agent.
Authorities — In the Telescript cloud, anonymity was precluded. Every agent possessed an unforgeable Telename — a combination of its identity and its Authority (the physical-world person or organization it represented).
Cryptographic Proof: A network “Region” would verify an agent’s authority via cryptographic proof before granting entry.
Accountability: Because an agent’s authority was verifiable and its Telename was permanent, a server agent could bill a user’s authority for services rendered. This prevented the “unbridled consumption of resources” and effectively barred the spread of anonymous digital viruses.
The Telescript Engine (The Virtual Machine)
The Engine was not merely a sandbox; it was a sophisticated Virtual Machine/Interpreter. It ensured that agents never touched the host processor or memory directly. Instead, the Engine drew on host resources through three strictly defined APIs:
Storage API: To preserve the persistent state of agents during computer failures.
Transport API: To manage the migration of agents across media (TCP/IP, X.25, or even email).
External Applications API: To allow the Telescript environment to interact safely with legacy C or C++ code.
Conclusion: Why Voluntary Safety Won’t Be Enough
We are currently giving LLMs the keys to our digital lives—our credit cards, our calendars, and our passwords—without Permit systems or deterministic guardrails that Jim White and the General Magicians designed to prevent “unbridled consumption of resources.”
The history of General Magic proves that we are not obligated to choose between autonomy and safety. The blueprints for safer autonomous systems already exist. Telescript demonstrated that deterministic safety can work in concert with powerful, autonomous systems. Remote Programming gave us true agent mobility. Permits gave us resource limits. Authorities gave us accountability.
We do not need to reinvent agent safety. We need to remember it—and we need to demand it.
Agentic AI promises convenience and power, but without the “rules of the road” that Telescript codified thirty years ago, we’re building the extractive systems with more powerful tools. AI agents can serve us or surveil us, empower us or exploit us. The answer isn’t predetermined by the technology—it’s determined by who builds it, how it’s governed, and whether we demand structural safeguards before it’s too late.