ASys (Agentic System Interface) is an open-source system interface protocol designed specifically for AI Agents — binary instructions instead of text commands, persistent connections instead of per-request handshakes, instruction-level permissions instead of broad session-level access. This is where it came from and why it's built the way it is.
Last year, using Claude to help write code felt like working with an intern with terrible memory. Context would drift as conversations grew longer. Restarting a session meant spending several rounds just getting back to where we were. Interfaces we'd agreed on earlier would be forgotten later.
Early this year I tried again. I used Claude Code to build ReCall — a PySide6 desktop flashcard app with config, UI, database, i18n, a theme system, tests, and Windows packaging. Not huge in scope, but it covered everything a real desktop app needs. The experience was completely different. I was still driving, but Claude could keep up. I'd say what needed doing, and it understood accurately. The code mostly worked. When it went off track, a correction pulled it back fast.
The progress between those two experiences was obvious.
Looking back, the domains where LLMs have actually shipped: text and code. Both share something: they're tasks with a finish line — write an article, ship a feature, done. Operations is different. Once a system is live, it's real-time, stateful, and problems arrive without warning. There's no "done." It's a different world entirely.
I was studying for CompTIA A+ Core 2 at the time — reviewing during the day, writing code at night. One question kept turning over in my head: AI assistance for development is maturing fast. What about ops?
When the Operator Becomes an AI
Once AI accelerates development to an exponential pace, the accumulation of running systems accelerates with it. Every new service deployed is something that needs maintaining — indefinitely. Systems don't disappear. Problems pile up. Complexity compounds. Think of it this way: all running systems together form a large lake; all systems under development are rivers flowing into it. As more rivers flow faster, the lake grows faster than anyone expects.
But human ops scales linearly. One engineer can only maintain so many systems, no matter the tooling. Human ops can't keep up with exponential accumulation. Looking ahead, only AI ops can take that on.
For AI ops to work, though, one prerequisite needs solving: the interface.
From POSIX to SSH, from Ansible to Kubernetes Operators — these tools are battle-tested, widely deployed, and will keep running for years. But every one of them was designed with a human operator in mind. When the operator becomes an AI Agent, several things are worth rethinking from scratch: text parsing fails whenever output format changes; session-level permissions carry serious risk for Agents that can hallucinate; frequent sampling makes per-connection handshakes a real bottleneck.
Take the cost of "guessing text." An Agent running ps aux | grep nginx over SSH gets back free-form text — format varies by OS, locale, and tool version. The Agent has to parse it, and every regex that might break is a potential hallucination entry point. Call ASys's SYS_PROCS instead, and you get a fixed 44-byte binary frame: process count, top-5 PIDs, CPU%, memory%, status flags. Typed, unambiguous, identical on every node. Parsing is one line of struct.unpack. This isn't just a performance gain. It's a reliability improvement of a different order. When parsing overhead approaches zero, the Agent can spend nearly all its compute on what actually matters: perception, reasoning, decision.
ASys isn't trying to replace any of these tools. It's exploring one question: if you designed an interface specifically for Agents, from first principles, what would it look like? One more option, that's all.
Open source: github.com/vincentping/asys
Where ASys Came From
From 2010 to 2016, I worked as a developer at a smart card company in Shanghai — SIM cards, bank cards, ID chip cards. The industry had one iron rule: once a card ships, you can't take it back.
Smart card development meant writing the spec first, implementing against the spec, testing against the spec: functional tests, failure tests, edge case coverage. After internal testing came on-site testing at the telecom operator. Tedious, long-cycle, no shortcuts. Because if you found a bug after mass production, the recall cost was catastrophic. That's a completely different philosophy from the move-fast-and-iterate approach of internet development. The deepest thing those six years left me wasn't any particular technology. It was an instinct: thinking it through and writing it down matters more than starting fast.
Those six years also made me fluent in protocols. Especially ISO/IEC 7816 — the APDU system for smart card communication. A card reader sends binary instructions to a smart card and gets back a fixed-format response, never parsed by human eyes. 0x9000 means success. 0x6982 means security status not satisfied. Unchanged for decades. This protocol runs on tens of billions of devices — every bank chip card, every e-passport, every SIM card. Every edge case has been validated in the hardest production conditions possible.
After 2016, I left smart cards and spent the next ten years building web systems of all shapes — frontend JS, backend Python/Go/Java, databases, servers, caches, clouds, various architectures.
The past year I've been deep in AI, building projects with Claude. The more I understand it, the more convinced I am: AI will reshape humanity the way the Industrial Revolution did. After finishing ReCall, I kept asking myself what to build next that was actually AI-related.
One night in late February — studying late, just lay down, half-asleep — APDU from 7816 flashed into my head. Those elegantly simple binary instructions, fixed-format responses. I sat straight up. Why not use APDU-style communication between Agents and servers? Why keep human-readable text in the middle at all?
That same night I re-read the 7816 spec, wrote a rough document, got the initial idea down.
Six years in smart cards, ten years in web systems, one-plus years in AI — take away any one of those, and that half-asleep connection doesn't happen. Most of my old smart card colleagues are still in embedded systems. My web friends rarely have a background in low-level protocol design. Maybe this is what people mean when they say diversity drives emergence. Once the idea showed up, not trying it felt like a waste.
Three Months, Zero to Open Source
Early March — A+ Core 2 still not done — I started anyway.
Old habit from smart card days: write the docs first. Interface design philosophy, instruction set encoding, security model, frame format — think each piece through, write it up, realize mid-writing that I hadn't thought it through, go back. March 16, v0.1 docs done. Same day, first PoC running between a Windows machine and a RHEL server: SYS_HELLO instruction, response 0x9000 OK.
After the exam, progress accelerated. Docs and code alternated. Write code, find a design problem, go fix the spec, continue. Not throwing things away and starting over — just continuous refinement.
A few decisions in this process each took time to work through.
Transport: Why Not mTLS
Transport layer was the first thing that stopped me. Instinct said mTLS — common, widely used, easy to debug. But the more I thought about it, the more wrong it felt.
asyd is ASys's server-side daemon. One of its core use cases is staying reachable during OOM events, full disks, exactly the moments you need it most. If it goes silent because a certificate expired or the CA is unreachable at that moment — an interface that fails during emergencies is more dangerous than no interface at all. And OpenSSL is a heavyweight dependency. That directly conflicts with the zero-external-dependencies design goal.
I went with Noise Protocol IK, implemented on Monocypher. Pure cryptographic primitives, no certificate dependencies, roughly 2,000 lines of C, fully auditable, 1-RTT handshake. This choice lets asyd ship as a single static binary. Deploy it on any POSIX environment with no runtime risk.
Permission Model: Making Unauthorized Things Not Exist
The permission model took longer. The intuitive answer was an ACL table — configure which Agent can do what. Simple-looking, but not enough.
Traditional security models (SSH, sudo) were designed for human operators. Human actions are exploratory; intent is hard to declare upfront. "Broad default permissions plus negative interception" fits how humans work. When the operator is an AI Agent, that assumption breaks. Agent behavior is programmatic. Permission boundaries can be declared precisely at deployment time.
So ASys flips it. The system is dark to an Agent by default. Only instructions explicitly lit up in the Capability Map "physically exist." An unauthorized operation isn't "you don't have permission" — it's "this instruction doesn't exist in your world." Unregistered instructions are dropped at the decode stage and never enter any execution path.
Using a bitmap has an additional benefit: side-channel resistance. If you check permissions before checking existence, an attacker can infer which instructions "exist but are disabled" through tiny timing differences in responses. The Capability Map forces existence-check first. All unauthorized operations produce identical response timing. No information leakage surface.
Least privilege isn't a configuration option. It's a physical property of the protocol.
Instruction Set: How to Organize 256 Slots
The instruction set structure came together faster, because there was an obvious reference: APDU.
Frame format borrowed directly: [CLA][INS][P1][P2][Lc][Data][Le]. The high nibble of the INS byte serves as a logical page index — 0x00–0x0F is Core ISA, the baseline observation instructions, permanently locked; 0x20–0x8F is Standard ISA, seven functional groups; 0xC0–0xFF is Vendor Extensions, open for domain-specific customization.
Any developer reading an instruction code knows the group at a glance. 0x2x is Process Control, no table lookup needed.
More important is the semantic lock on Core ISA: once a core instruction ships, byte offsets never change. New fields can only be appended at the end. Agent parsing code written today is expected to work on some POSIX-compatible system fifty years from now. APDU covers tens of billions of devices precisely because of this long-termism. That's what ASys is trying to inherit.
Closing the OODA Loop
Late May, I ran a complete OODA loop demo on RHEL. The RHEL server ran a CPU hog to trigger a load spike. A Python client on Windows called SYS_STATUS to detect the anomaly, SYS_PROCS to locate the process, PROC_THROTTLE to suppress it, then SYS_STATUS again to confirm recovery. All 0x9000 throughout.
That moment didn't feel like "it works." It felt like "proof of concept confirmed."
May 27, v0.3.0 released. Three months from idea to open source.
Where Things Stand
github.com/vincentping/asys is now at v0.3.1.
Stable today: Core ISA's four observation instructions (SYS_CAPS / SYS_HELLO / SYS_STATUS / SYS_PROCS), the first batch of Standard ISA control instructions (PROC_THROTTLE / SVC_RESTART / TASK_QUERY), a complete Noise IK encrypted channel, public key whitelist authentication, and Epoch_ID replay protection.
The most important next piece is the Python SDK — targeting AI Agent developers, designed to drop into LangChain, AutoGen, and similar frameworks. The core design principle: Agents never touch the byte layer directly. They call structured interfaces (sdk.proc_throttle(pid=1234, action="stop")); the SDK handles parameter validation and binary compilation. LLMs are inherently bad at byte offsets. Having an Agent assemble raw APDU parameters is the wrong abstraction.
Still planned but not yet implemented: per-Agent fine-grained Capability Maps, an audit black box, chained transport. All in the spec. All coming.
Honest Thoughts
Building a protocol solo sounds a little crazy.
Protocols are usually a committee job — they need multi-party consensus, large bodies of real-world input, exhaustive edge case analysis. But the idea showed up. So I tried. Working alone means decisions move fast. It also means no external pressure forces you to think every corner through. My response has been the same as in smart card days: docs before code. White paper, protocol spec, design notes, implementation notes — these took more time than the code itself. Because writing is the best thinking tool I have. If I can't write it clearly, I don't actually understand it. If I don't understand it, the code will collapse eventually.
ASys is an exploratory project. It's not a replacement for SSH, not a competitor to Ansible. The gap it's trying to fill: when an Agent needs to manipulate a system at high frequency, low latency, and with full auditability — while staying reachable in extreme conditions — there's currently no purpose-built standard for that. Wrapping an LLM around SSH and calling it AI ops doesn't solve the underlying problem.
Whether that's worth solving is for others to judge. But I think as Agents move further into production systems, the question "what should the interface between an Agent and a system actually look like?" deserves serious attention.
If ASys starts that conversation, that's enough.
One last note: ASys listens on port 7816 by default. A deliberate tribute to ISO/IEC 7816 — the standard number for smart card communication protocols. Every time I see that number, I'm back in front of a stack of specs from a decade ago: 7816, 14443, EMV, PBOC, UICC, RSA. The years I spent with my face in those pages.