Introduction
Vicunous is building toward becoming an AI-native, agent-first company. The end state we are working toward: every business operation, from writing code to running ad campaigns, is executed by autonomous agents backed by foundation models. Not AI-assisted. Not copiloted. Agent-executed. We are not there yet. But this is the architecture we are building into, and every system we ship is designed to move us closer.
This design principle has a name: A3I, AI-Native, Agent-First, Adaptable Intelligence. AI-native means every system is built on large language models (LLMs) and multi-modal foundation models from the ground up, not retrofitted onto legacy workflows. Agent-first means LLM-powered agents are the default operators, running agentic loops (observe → reason → act → observe), invoking tools via function calling, and completing tasks autonomously. Adaptable means the system translates its own outputs across modalities and audiences using inference-time generation, not static templates. These three properties describe where we are headed; the V Stack described below is how we get there.
Building an A3I organization requires an operational stack, a clear decomposition of responsibilities so that each part of the system can evolve independently. We model ours on the Open Systems Interconnection (OSI) reference model: the same layered architecture that standardized network communication in the 1980s, applied to the orchestration of multi-agent systems.
This post describes the V Stack, our seven-layer A3I architecture. We start with a brief account of why the OSI model works as a structural reference, then walk through each layer of the V Stack and what it does at Vicunous. (For a concrete walkthrough of how the OSI layers work using an everyday example, see Appendix A.)
The OSI Model as a Design Reference
The Open Systems Interconnection model was published by ISO in 1984 (ISO 7498) to solve a coordination problem: network hardware and software from different vendors could not interoperate. The solution was modularization, decomposing communication into seven layers, each with a defined responsibility and a contract with its neighbors. OSI did not prescribe protocols; it prescribed boundaries. The actual protocols that filled those boundaries (TCP/IP, HTTP, TLS) provided the standardization: shared contracts that let independently built components interoperate without knowing each other's internals.
| OSI Layer | Name | Responsibility | V Stack Counterpart |
|---|---|---|---|
| L7 | Application | End-user services and interfaces | V Interface |
| L6 | Presentation | Data format translation and encryption | V Adapter |
| L5 | Session | Connection lifecycle management | V Router |
| L4 | Transport | Reliable end-to-end data delivery | V Agents |
| L3 | Network | Routing and logical addressing | V Skills |
| L2 | Data Link | Node-to-node frame delivery | V Tools |
| L1 | Physical | Raw bit transmission over a medium | V Artifacts |
TCP/IP won the protocol war, not OSI. But the reference model endured because it solves two problems that recur in any complex system: modularization, separating concerns so that components can evolve independently and fail in isolation, and standardization, defining stable contracts so that independently built components can communicate without tight coupling. These are the properties that make it useful as a design reference for agent-first infrastructure. Not the networking specifics, but the structural discipline: modularization for independent evolution, standardization for reliable interoperation.
The V Stack
The following sections describe each layer of the V Stack from bottom to top: what it does, how it maps to the OSI model, and what role it plays in the A3I architecture at Vicunous.
L1 — V Artifacts
This is where wisdom resides.
OSI parallel: Physical Layer—where raw bits reside on a medium.
V Artifacts store the persistent state and memory of the organization. In LLM terms, this layer is the grounding corpus, the source material that gets retrieved and injected into agent context windows at inference time. Everything the company knows, documents, images, audio, video, structured records, configuration files, lives here.
| Artifact Type | Storage | Editing Interface |
|---|---|---|
| Context (text, image, audio, video) | GitHub repositories | IDEs, GitHub UI, HackMD |
| Structured data | SaaS systems (CRM, HRIS), spreadsheets | Source SaaS platform |
| Domain-specific foundation models | Model registries, fine-tuned weights | Training pipelines |
Artifacts are heterogeneous by nature. Unstructured context (text documents, images, audio, video) lives in GitHub repositories, version-controlled with the same rigor as source code: auditable, diffable, branchable. Structured data lives where it originates: CRM records in the CRM, HR data in the HRIS, financial figures in spreadsheets. Fine-tuned model weights live in model registries. The design decision is that every artifact has a defined home, a known schema, and a retrieval path that agents can follow. When an agent at L4 needs to reason over company knowledge, L1 is where it looks. In our Vision post, we introduced the Funding Foundation Model (FFM) as a domain-specific foundation model for funding transactions; at L1, the FFM weights and training data are among the artifacts that ground agent reasoning.
L2 — V Tools
This is where data becomes executable.
OSI parallel: Data Link Layer—the functional interface for node-to-node frame delivery.
Tools are the function-calling interface between LLM agents and external systems. In the language of model providers, each tool is a tool_use schema: a name, a description, and a typed parameter set that the model can invoke during its agentic loop. A Bash terminal, a web browser instance, an API client, a file system accessor: these are the execution primitives that give agents the ability to act on the world beyond the context window.
Tools do not contain business logic. They provide raw capability ("execute this command," "call this endpoint," "read this file") and return structured results that feed back into the agent's reasoning chain.
At Vicunous, every tool an agent can invoke is defined as a versioned configuration following our internal V Tool Schema specification: a typed schema that the model reads at inference time to understand what it can call and what parameters to pass. When we add a new external integration (a CRM API, a document signing service, a payment processor), we register it as a tool at L2. Agents at L4 never call external systems directly; they invoke tool schemas, and the tool layer handles execution and response parsing.
L3 — V Skills
This is where the capability is codified.
OSI parallel: Network Layer—routing specific capabilities to their destination.
A skill is a granular, encapsulated capability that an agent can invoke. Following Anthropic's definition: a composed procedure with a defined input, a defined output, and a specific sub-task it accomplishes. In implementation terms, a skill is a prompt chain bundled with a tool sequence and an output schema, a repeatable multi-step inference pattern that produces a structured result.
Skills sit between tools (raw function-calling interfaces) and agents (which orchestrate multiple skills within an agentic loop). A skill uses one or more tools from L2 to accomplish its work. Skills are reusable: the same skill can be invoked by different agents operating in different business domains, because the skill's prompt template and tool sequence are decoupled from the agent's system prompt and identity.
L4 — V Agents
This is where the work gets done.
OSI parallel: Transport Layer—reliable end-to-end delivery.
V Agents are the worker nodes. Each agent is a configured LLM instance running an agentic loop: receive a task, reason over the context window, select and invoke skills, observe tool results, and iterate until the task is complete. In a traditional organization, this layer maps to individual contributors. In an agent-first organization, it maps to autonomous agents backed by foundation models that operate across every business function.
| Domain | Example Agent Work | Primary Model Capabilities Used |
|---|---|---|
| Engineering | Write features, review PRs, deploy to production | Code generation, chain-of-thought, tool use |
| HR | Generate onboarding documentation, draft job descriptions | Document synthesis, structured extraction |
| Sales | Qualify leads, draft proposals, prepare deal collateral | Reasoning over financial data, long-form generation |
| Marketing | Create campaigns, generate content, manage ad distribution | Multi-modal generation, style adaptation |
| Operations | Automate processes, generate reports, maintain internal docs | Data aggregation, tool orchestration |
Each agent's identity is a configuration: a system prompt that defines its role and behavioral constraints, a skill manifest that declares which L3 capabilities it can invoke, a tool access list that gates which L2 interfaces it can call, and guardrails that bound its output (e.g., token limits, content filters, required output schemas). These configurations live in GitHub, go through code review via pull requests, and deploy through standard CI/CD. An agent's capabilities are not emergent; they are explicitly defined, versioned, and auditable.
L5 — V Router
This is where intelligence theory turns into application.
OSI parallel: Session Layer—managing the lifecycle of sessions between components.
The Router is the coordination and resource management layer. When a high-level business goal arrives ("prepare a funding memo for this company," "onboard this new team member," "launch this marketing campaign"), the Router decomposes it into sub-tasks, coordinates which agent (and which underlying model) handles each sub-task, manages inter-agent context passing, and tracks completion across the full workflow.
At Vicunous, the Router handles:
- Task decomposition: Breaking a business objective into executable agent tasks, each scoped to fit within a single agent's context window and skill set
- Model routing: Selecting the appropriate foundation model per sub-task, high-capability models (e.g., Claude Opus) for complex reasoning, faster models (e.g., Claude Haiku) for structured extraction
- Context budgeting: Deciding what artifacts, prior outputs, and shared state to inject into each agent's context, budgeting token capacity across the workflow to balance grounding fidelity against cost and latency
- Sequencing: Coordinating execution order when tasks have dependencies, ensuring agent B receives agent A's output before starting inference
- Failure recovery: Detecting insufficient output (via structured output validation or confidence signals) and re-routing to a different agent or model
The Router is where the intelligence metrics we develop under our Intelligence Theory research theme become operational, a topic we will cover in a forthcoming post. Coordination decisions (which model handles which sub-task, how to budget context window capacity across a multi-agent workflow, when to escalate from a lightweight model to a high-capability one) are resource management problems applied to cognitive compute.
L6 — V Adapter
This is where adaptive agency happens.
OSI parallel: Presentation Layer—translating between internal and external data formats.
The V Adapter is the inference-powered translation protocol. Internally, all agent outputs are standardized in a Multi-modal V Message protocol, a structured representation carrying text, data, references, and metadata in a consistent schema. The Adapter uses model inference, not static templates, to convert these internal representations into the format required by the target interface at L7.
The same V Message might be transformed into:
- A rendered React component on vicunous.com (via schema-constrained generation targeting JSX output)
- A slide in an investor presentation (via long-form generation with audience-adapted register)
- A paragraph in a notification email (via concise summarization with domain-specific terminology)
- A structured JSON payload for a downstream API (via structured output with strict schema adherence)
The Adapter does not just reformat. It runs inference to make editorial decisions: what to include, how to structure the narrative, what level of technical detail fits the audience. A funding analysis produced by an L4 agent contains raw financial metrics, risk scores, and source references stored as a V Message. The Adapter protocol takes that structured payload, reasons over the target audience, and generates a concise memo for an investor, a detailed breakdown for an underwriter, or a summary card on the platform, each produced by a separate inference pass over the same underlying data, with different system prompts governing tone, depth, and format. The Funding Operating System (FOS) introduced in our Vision post operates primarily at this layer, serving as the adaptive translation surface that converts raw agent intelligence into funding-domain outputs across audiences and modalities.
L7 — V Interface
This is where laymanization happens.
OSI parallel: Application Layer—where end-users interact with the system.
The V Interface is every touchpoint where a human-in-the-loop interaction occurs, whether with internal users (team members reviewing agent output) or external users (investors, business owners) consuming the final product. Everything rendered here has passed through all six layers below: retrieved from artifact storage, processed by tool interfaces, composed by skill prompt chains, executed by LLM-powered agents, orchestrated by the multi-agent router, and translated by the inference-driven adapter.
| Interface | Examples | Generation Path |
|---|---|---|
| Web | vicunous.com, the investment platform | Agent → V Message → Adapter → React component |
| Marketing | Advertisements, social media, campaigns | Agent → V Message → Adapter → platform-native copy |
| Collateral | Pitch decks, sales materials, research posts | Agent → V Message → Adapter → document format |
| Communication | Emails, reports, investor notifications | Agent → V Message → Adapter → email/notification |
The end user does not see agents, skills, tools, context windows, or V Messages. They see a funding memo, a term sheet, a dashboard, a research article. The full inference pipeline, from artifact retrieval through multi-step reasoning to audience-adapted generation, is abstracted into a single rendered output.
The V Agent Builder
The Control Plane
The V Agent Builder sits outside the inference path. It does not process business tasks; it creates and maintains the components that do. It is the centralized factory for authoring system prompts, defining skill prompt chains, registering tool schemas, and configuring the guardrails that govern agent behavior.
The Builder operates as a thin, specialized layer on top of Claude Code. It can be accessed via CLI, the Claude desktop or browser applications, or integrated into an IDE (VS Code, JetBrains).
| Concern | Builder's Role |
|---|---|
| Agent creation | Author system prompts, define skill manifests, set tool permissions |
| Skill authoring | Design prompt chains with typed I/O schemas and tool sequences |
| Tool registration | Define function-calling schemas mapping to external system interfaces |
| Version control | All configurations committed to GitHub as code |
| Deployment | Configurations deployable via standard CI/CD |
Every agent, skill, and tool at Vicunous was built through the V Agent Builder. This includes the agent that wrote the first draft of this post, the skill that handles publishing it, and the tool that sends the notification email when it goes live.
Full Stack Summary
| Layer | V Component | Tagline | What Lives Here |
|---|---|---|---|
| L7 | V Interface | This is where laymanization happens | Web, marketing, collateral, comms |
| L6 | V Adapter | This is where adaptive agency happens | Multi-modal V Message → human formats |
| L5 | V Router | This is where intelligence theory → application | Task decomposition, agent orchestration |
| L4 | V Agents | This is where the work gets done | Eng, HR, sales, marketing, ops agents |
| L3 | V Skills | This is where the capability is codified | Reusable encapsulated procedures |
| L2 | V Tools | This is where data becomes executable | Bash, browser, API clients, file I/O |
| L1 | V Artifacts | This is where wisdom resides | GitHub repos, SaaS data, org memory |
A3I is not a product. It is an operational architecture, a way of structuring an organization so that autonomous agents can execute every business function through a stack with defined layers, stable contracts, and independent evolution. Because every configuration is version-controlled and every layer boundary is explicit, the entire stack is observable and explainable: you can trace any output back through the adapter, router, agent, skills, tools, and artifacts that produced it. Observability is not bolted on; it is a structural property of the layered design. The OSI model demonstrated that this kind of decomposition scales for network communication. We are applying the same structural discipline to intelligence.
References
- Zimmermann, H. (1980). OSI Reference Model—The ISO Model of Architecture for Open Systems Interconnection. IEEE Transactions on Communications, 28(4), 425–432.
- ISO/IEC 7498-1 (1994). Information technology—Open Systems Interconnection—Basic Reference Model.
- Anthropic (2025). Building effective agents. Anthropic Research.
Appendix A — OSI Example
To make the seven-layer model concrete, consider what happens when you open a browser and load a webpage, say vicunous.com.
L7 — Application. You type a URL into Chrome and press Enter. The browser, the application, initiates an HTTP request. This is the layer you interact with: a human-readable interface that hides everything below it.
L6 — Presentation. The browser and server negotiate TLS encryption. Your request is encrypted before it leaves your machine; the server's response is encrypted before it leaves theirs. This layer also handles data format translation: compressing payloads, encoding character sets, serializing structured data. You never see this negotiation. It happens transparently so that both sides can understand each other's data regardless of internal representation.
L5 — Session. HTTP manages the dialogue between client and server. Keep-alive negotiation determines whether a single underlying connection carries multiple request-response exchanges or closes after each one. The session layer governs this lifecycle: opening a logical dialogue, maintaining state across related exchanges, and tearing it down cleanly when the conversation is complete.
L4 — Transport. TCP handles connection establishment and reliable delivery. It opens a connection via a three-way handshake, then splits the HTTP request into segments, each with a sequence number. If any segment is lost in transit, TCP detects the gap and retransmits it. The transport layer guarantees that the full message arrives intact and in order, regardless of what the network below it does.
L3 — Network. IP addressing and routing. Your request is wrapped in IP packets, each stamped with a source address (your machine) and a destination address (the server). Routers across the internet read these addresses and forward each packet hop by hop toward the destination. This layer does not guarantee delivery; it just handles addressing and path selection.
L2 — Data Link. Each IP packet is framed for the specific physical link it traverses. On your home Wi-Fi, it becomes a Wi-Fi frame with a MAC address. When it hits the ISP's fiber backbone, it is reframed for that medium. At each hop, the data link layer handles node-to-node delivery: getting the frame from one device to the next device on the same local network.
L1 — Physical. The actual signals: electrical pulses on copper, light pulses in fiber optic cable, radio waves over Wi-Fi. This layer is raw transmission: no logic, no addressing, just bits moving through a physical medium.
Disclaimer. This post describes the V Stack—the target architecture Vicunous is building toward as an AI-native, agent-first organization. It reflects our design philosophy and operational roadmap. Individual layers are at varying stages of maturity, and all agent workflows include human oversight appropriate to the domain, legal and regulatory considerations, and the decision stakes.