LLM Architecture: Tokens, Context, Skills, and Agents

The integration of generative AI is no longer just about chat interfaces; it has become a direct software architecture challenge. Understanding how the engine of these tools works is what separates an inefficient API call from a truly autonomous system. The hype is over; now the discussion is pure engineering.

Below are the four technical pillars that structure this layer.

Tokens

The fundamental unit of processing. Language models do not interpret raw text; they process numerical matrices. The raw input and output text is fractionated into these fragments called tokens. The billing, latency, and computational cost of any request strictly depend on this volume. The efficiency of an integration is measured by the density of useful information per token spent, which requires constant optimization of what travels over the network.

Context Window

It is the short-term memory of the request. Each model has a strict architectural limit of tokens it can retain and process simultaneously in a single call. Exceeding this limit results in the silent loss of initial instructions. In real-world projects, we bypass this structural limitation by avoiding sending entire databases. Instead, we implement data retrieval pipelines that inject into the context only the strictly necessary scope milliseconds before the final submission to the model.

Skills (Function Calling)

The mechanism to break the structural isolation of the model. It is the bridge between the analytical capability of AI and the execution of your code. The model receives the signatures of the functions and routines available in your system. When processing the request, instead of generating free text, it generates a structured data payload indicating which function of your software should be executed. The system processes the business logic and returns the output for the model to continue the operation. This is the touchpoint where abstraction gains access to the production environment.

Agents

The peak of control abstraction. Unlike traditional imperative flows, agent-based architecture inverts system management. Instead of declaring a linear step-by-step process, you define an end state or objective. The model evaluates the intent, selects the declared Skills in the system, receives the return from each execution, and recursively decides the next action. It represents the transition from a purely reactive system to an autonomous one, serving as the foundation for architectures where multiple isolated agents collaborate on the same solution.

---

Putting the pieces together: How to apply this in practice

Theory is elegant, but engineering happens in the trenches. When you bring these four pillars into the development of a real product—like a multi-tenant SaaS or a micro-frontend architecture—the workflow changes radically.

Here are real examples of how to orchestrate these elements.

1. Optimizing Tokens and Context in Migration Logs

Imagine you are leading a complex migration from legacy systems to a new architecture and need to use AI to analyze failures. If you dump a 50MB log file into the prompt, you will blow up the Context Window and burn money on useless Tokens.

The real solution: You create an intermediary script that filters the log locally. The system extracts only the lines containing the [ERROR] or [TIMEOUT] tags referring to a specific tenant_id. You package only this refined text extract (now at just 800 tokens) and inject it into the request's Context Window. The AI receives only the clean signal, without the noise, and returns the diagnosis of the problem quickly and cheaply.

2. Controlling the Frontend with Skills (Function Calling)

You want to put a smart search bar in a management dashboard. The user types: "Filter inactive users from last month".

The AI doesn't have access to your database to do this. This is where Skills come in.

• The Flow: You send the user's input to the AI, passing along a JSON schema for a Skill called applyUserFilter(status, dateRange).
• The Magic: The AI doesn't respond with friendly text. It returns a structured JSON: { "function": "applyUserFilter", "args": { "status": "inactive", "dateRange": "2026-06" } }.
• On the Frontend: Your code intercepts this response, applies these arguments directly to the state of your application (for example, updating a Signal in Angular), and the table on the screen is rendered instantly with the correct data. The AI operated the interface for you.

3. Orchestrating Agents for Autonomous Tasks

Think of an onboarding flow for a new client in your SaaS system. Instead of writing rigid code that hits 5 different APIs in sequence, you define a Provisioning Agent.

You give it a goal: "Configure the environment for the new Tenant X". The Agent, running in the backend, analyzes the task and decides its own actions:

1. It triggers the createDatabaseSchema() Skill.
2. Evaluates the response (was it successful?).
3. Triggers the provisionMicroFrontendRoute() Skill.
4. It realizes the routing API returned a timeout error. Because it is an Agent, it has the autonomy to reason about the error and decides to trigger the Skill again (retry) without you having programmed that specific if/else.
5. When everything is finished, it triggers the sendSlackNotification() Skill, notifying that the environment is live.

You stopped being a programmer of imperative flows and became an orchestrator of capabilities.