A Discovery Worth Understanding Carefully

Last week, Anthropic announced that Claude had found a previously unknown enzyme system in the DNA of bacteriophages, the viruses that infect bacteria. The Claude enzyme discovery drew fast headlines. Many of them ran ahead of the facts. Some called it the next CRISPR. Anthropic itself was far more careful.

This article explains the Claude enzyme discovery in plain steps. It covers how the work was done, what was found, and what still needs to be proven.

A Race That Escalated Fast

Eight separate organizations filed plans, launched hardware, or committed funding to build orbital data centers within just the last 90 days. This is no longer a speculative concept discussed at tech conferences. Google confirmed this week it is moving forward with its own orbital compute program. SpaceX and xAI have filed for up to one million satellites. Jeff Bezos has described gigawatt-scale facilities in orbit within a decade or two. Elon Musk, Eric Schmidt, and Sam Altman have all weighed in publicly. This article examines exactly what is being built, why, and whether the underlying economics actually make sense yet.

This is Part 3, the final article in a three-part series on the modern data analytics stack. Part 1 covered sources, ingestion, and storage. Part 2 covered processing and modeling. Part 3 covers visualization, deployment, and data pipeline orchestration.

Where Engineering Meets the End User

Parts 1 and 2 of this series covered how raw data becomes clean, modeled, analyzable data. This final article covers what happens next. How that data reaches human decision-makers through visualization, how analytical tools get shipped as real applications, and how the entire pipeline stays reliable through proper data pipeline orchestration. This is where engineering rigor either pays off visibly or quietly fails at the last mile.

This is Part 2 of a three-part series on the modern data analytics stack. Part 1 covered sources, ingestion, and storage. Part 2 covers the data processing layer itself, transformation, and modeling. Part 3 will cover visualization, deployment, and orchestration.

Where Raw Data Becomes Useful Data

Part 1 of this series ended with data sitting in a warehouse, stored and queryable but still essentially raw. The data processing layer is where that raw material gets shaped into something an analyst, a model, or a dashboard can actually consume. This article goes deep into the specific engineering behind Spark, dbt, Pandas, and the analysis tools that sit downstream of them.

This is Part 1 of a three-part series on the modern data analytics stack. Part 1 covers data sources, ingestion, and storage architecture. Part 2 will cover processing, transformation, and modeling. Part 3 will cover visualization, deployment, and orchestration.

Why the Stack Exists at All

Every analytics system solves the same underlying problem. Data is born scattered, messy, and structurally inconsistent. A production database, a sensor feed, and a spreadsheet an analyst maintains by hand share almost nothing in common technically. The data analytics stack exists specifically to move raw, heterogeneous data through a series of transformations until it becomes something a human or a model can actually reason about. This first article covers the foundation. Where data originates, how it gets captured, and how it gets stored once captured.

From Fixed Rules to Reasoning Machines

For decades, algorithmic trading meant fixed rules. If a stock’s RSI drops below 30, buy. Simple. Mechanical. Predictable. AI trading agents work differently. They read earnings transcripts, news articles, and price data, then reason in natural language about what it all means. If 2025 was the year quant funds quietly rebuilt their stacks around large language models, 2026 is the year AI trading agents stopped being a curiosity and started moving real capital.

This article covers how these systems actually work, the specific strategies driving adoption, and the genuine risks nobody should ignore.

A Strange Question That Is Suddenly Not So Strange

For decades, upgrading a computer meant a physical transaction. You bought a stick of RAM, slotted it into a motherboard, and your machine had more memory. You bought a graphics card, installed it, and your machine could render games or train neural networks. Intelligence itself never worked this way. It lived in the cloud, behind an API, rented by the token, controlled entirely by whichever company trained the model. In 2026, a genuinely interesting question has moved from science fiction into serious industry discussion: can we turn today’s large language models into an AI hardware component, something you install the way you install a GPU card, rather than something you subscribe to?

The answer, examined carefully, is more nuanced than a simple yes or no. Parts of this vision are already real and shipping today. Other parts remain years away, constrained not by ambition but by physics, memory bandwidth, and software maturity that has not caught up with the hardware.

What an AI Hardware Component Actually Requires

To understand whether an LLM can become a true AI hardware component, it helps to break the idea into its constituent parts. A GPU card works as a component because it is self contained, it has its own memory, its own processing units, and a standard interface, PCIe, that any compatible motherboard understands. For an LLM to work the same way, three things need to exist simultaneously: a physical chip capable of running the model’s mathematics efficiently, enough fast memory located close to that chip to hold the model’s weights, and a standardised interface that lets any computer recognise and use the card without custom software written specifically for it.

Every one of these three requirements is currently only partially satisfied, and understanding exactly where the gaps are is the key to understanding how close we actually are to a true plug in AI hardware component.

The Chips That Already Exist

The good news is that specialised AI hardware component chips are not hypothetical. Neural Processing Units, or NPUs, are now standard in most premium laptops sold in 2026. Intel’s Lunar Lake platform, AMD’s Ryzen AI 300 series, and Apple’s Neural Engine each deliver 40 or more TOPS, trillions of operations per second, of dedicated AI processing power. Microsoft’s Copilot Plus PC certification requires exactly this threshold, and these chips genuinely do accelerate certain AI workloads locally, particularly small models and specific Windows AI features, with remarkably low power draw.

Beyond laptops, dedicated AI accelerator cards already exist in modular, pluggable form factors. M.2 cards such as the LLM-8850, built around a compact system on chip delivering 24 TOPS, slot directly into the M.2 connectors found in most modern PCs and single board computers, offering exactly the plug and play experience the question envisions, at least for smaller models. PCIe based AI accelerator cards, designed for edge servers and workstations, extend this same modular philosophy to larger workloads.

So in a genuine, practical sense, the AI hardware component already exists as a product category. The catch is what these components can actually run.

The Memory Bandwidth Wall

This is where the vision runs into real physics rather than marketing copy. A large language model is not primarily limited by raw computational speed. It is limited by memory bandwidth, the rate at which the model’s weights, often tens of gigabytes of them, can be moved from storage into the processing unit fast enough to keep up with generation. As one detailed 2026 hardware analysis put it plainly, buyers who see a laptop advertised with 40 or 50 TOPS assume this means the machine can run a large language model like Llama or Mistral locally. In practice, TOPS numbers tell you almost nothing about whether an AI hardware component can run a genuinely capable model at usable speed.

The distinction matters enormously. Thin, low power NPU chips, similar in architecture to those found in smartphone camera processors, are excellent at small, sustained tasks, but they simply do not have the memory capacity or bandwidth to hold and serve a 70 billion parameter model. As one 2026 hardware database bluntly summarises the situation, you should read the memory column, not the TOPS column, when evaluating whether any given AI hardware component can genuinely run a local LLM.

This is precisely why the current generation of serious local AI hardware component systems, such as AMD’s Ryzen AI Max Plus 395 platform or Nvidia’s new RTX Spark superchip, take a fundamentally different architectural approach than a simple plug in card. Rather than a small accelerator with its own limited memory, these are unified memory systems, where the CPU, GPU, and NPU all share access to a large pool, up to 128 gigabytes, of high speed memory on a single package. This lets a properly configured system run a 70 billion parameter model entirely without offloading work to slower system memory, something no simple plug in card with its own small onboard memory can currently achieve.

Component Intelligence: A New Way of Thinking About It

Technology analyst Shelly Palmer recently articulated a compelling framing for where this trend is actually heading, describing what he calls component intelligence: frontier class AI productised as commodity hardware and open weights that any company or individual can buy, own, embed, and run locally, with no dependence on a centralised model provider. This framing captures something important that a narrow focus on physical card form factors misses.

The real transformation into an AI hardware component is not only about a chip you slot into a motherboard. It is about intelligence itself becoming ownable, embeddable, and independent of a subscription relationship with a distant cloud provider, in the same way electricity became a commodity utility rather than something only large factories could generate for themselves.

Open weight models, discussed extensively elsewhere on this blog, are the software half of this equation. A capable open weight model, once downloaded, is functionally a piece of intelligence you now own outright. Pair that model with genuinely capable local hardware, and the AI hardware component vision starts to look less like science fiction and considerably more like the current trajectory of the entire industry.

The Software Gap Nobody Talks About

Even where the hardware genuinely exists, a surprising bottleneck remains largely invisible to casual buyers. As of mid-2026, the mainstream local LLM runtimes that most enthusiasts actually use, Ollama, llama.cpp, and LM Studio, do not route inference workloads to the dedicated NPU at all. They run on the CPU or GPU instead, leaving expensive, purpose built AI silicon sitting idle. This is not a hardware limitation. It is a software maturity gap, and it illustrates something important about the AI hardware component question: shipping the chip is only half the problem. Building a software ecosystem that actually knows how to use it, the way decades of driver development made GPUs universally usable, takes time that hardware announcements alone cannot compress.

What This Means Practically Today

For a reader asking whether they can walk into a store today and buy a genuine AI hardware component the way they would buy a RAM stick, the honest answer is a qualified yes, with important caveats attached. Small, efficient models in the 3 to 9 billion parameter range, handling the majority of real world everyday AI tasks, already run well on NPU equipped laptops and modular accelerator cards. For anything approaching frontier capability, a 70 billion parameter model or larger, you currently need either a unified memory workstation costing upward of $1,500, or continued reliance on cloud infrastructure.

The trajectory, however, is unmistakable. Every major chip maker, Intel, AMD, Nvidia, Apple, and increasingly open silicon efforts like Tenstorrent’s RISC-V based accelerators, is racing toward exactly this outcome: intelligence as a genuine, ownable AI hardware component rather than a rented cloud service. The gap between today’s reality and Palmer’s component intelligence vision is not conceptual. It is a specific, measurable gap in memory bandwidth, software routing, and price, and every one of those gaps is closing steadily, generation by generation.

Conclusion

Turning an LLM into an AI hardware component you install like a GPU card is not a distant fantasy. It is a spectrum of capability that already exists at the small end and is advancing rapidly toward the frontier end. The chips exist. The connectors exist. The open weights exist. What remains is the unglamorous, incremental engineering work of closing the memory bandwidth gap and building software that actually knows how to use the silicon already sitting inside millions of machines. When that work finishes, and current trends suggest it will finish faster than most people expect, buying intelligence may genuinely become as ordinary as buying memory.

Why Build an AI Agent from Scratch?

If you want to build an AI agent that actually works in production, the worst place to start is a pre-packaged framework that hides what is happening beneath the surface. Frameworks are useful once you understand what they are abstracting. Before that point, they make debugging nearly impossible and leave you unable to explain your own system’s behaviour.

This guide walks through seven concrete steps to build an AI agent from scratch using Python. By the end, you will understand precisely how each component of the agent works, how they connect, and what goes wrong when they do not. Whether you are a software engineer exploring AI, or a practising ML engineer who wants to move beyond single-turn API calls, building an AI agent from scratch is one of the most productive things you can do to advance your practical skills in 2026.

Step 1: Understand What an AI Agent Actually Is

Before writing a single line of code, you need a clear mental model. An AI agent is not a chatbot that answers one question at a time. It is a reasoning system that perceives a situation, selects an action, executes it, observes the result, and decides what to do next, repeating this loop until the task is complete.

The three components every AI agent needs are tools (functions it can call to interact with the world), memory (a record of what has happened so far), and a reasoning loop (the logic that connects perception to action). When you build an AI agent from scratch, you are constructing all three of these components yourself, rather than inheriting someone else’s implementation.

Step 2: Choose Your LLM and Set Up Your Environment

To build an AI agent from scratch, you need access to an LLM that supports tool calling. The OpenAI API and the Anthropic API both provide native tool-calling interfaces that tell the model when and how to invoke external functions. Set up your Python environment with the relevant SDK:

pip install openai anthropic python-dotenv

Store your API keys in a .env file and load them with python-dotenv. Never hardcode credentials in your agent code, as this is a security risk that becomes serious the moment your agent has access to external systems.

Step 3: Define Your Tools

Tools are the hands of your AI agent. Each tool is a Python function that the agent can call at runtime. Define them clearly, because the model reads your descriptions to decide when to use each one:

tools = [
    {
        "type": "function",
        "function": {
            "name": "web_search",
            "description": "Search the web for current information on any topic.",
            "parameters": {
                "type": "object",
                "properties": {
                    "query": {
                        "type": "string",
                        "description": "The search query to send."
                    }
                },
                "required": ["query"]
            }
        }
    }
]

Write tool descriptions as if you are explaining the function to a capable but literal colleague. Vague descriptions produce inconsistent tool selection, which is one of the most common failure modes when you build an AI agent from scratch.

Step 4: Write the System Prompt

The system prompt is the agent’s constitution. It defines its identity, its available tools, the format it must use to call them, and the conditions under which it should stop. A minimal but effective system prompt for a research agent looks like this:

You are a research assistant with access to web search.
Think step by step before acting. Use the web_search tool
to find current information. When you have enough information
to answer the task fully, return a final answer clearly labelled
as "Final Answer:". Never guess when you can search.

When you build an AI agent from scratch, the system prompt deserves as much attention as the code. A poorly written prompt produces unpredictable reasoning regardless of how well the rest of the system is engineered.

Step 5: Build the Reasoning Loop

The reasoning loop is the core of the agent. It sends the current conversation to the LLM, parses its response for tool calls, executes the tools, appends the results, and repeats:

def run_agent(task: str, tools: list, tool_functions: dict,
              max_steps: int = 10) -> str:

    messages = [
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user",   "content": task}
    ]

    for step in range(max_steps):
        response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
            tools=tools
        )
        message = response.choices[0].message

        if message.tool_calls is None:
            return message.content  # final answer reached

        for tool_call in message.tool_calls:
            fn_name = tool_call.function.name
            fn_args = json.loads(tool_call.function.arguments)
            result  = tool_functions[fn_name](**fn_args)

            messages.append(message)
            messages.append({
                "role": "tool",
                "tool_call_id": tool_call.id,
                "content": str(result)
            })

    return "Max steps reached."

Notice the max_steps guard. Every time you build an AI agent from scratch, this is non-negotiable. Without it, a confused agent will spin indefinitely and consume tokens until it hits a rate limit or your budget runs out.

Step 6: Add Memory

In-context memory is built into the loop above: the entire conversation history is passed to the LLM at each step, giving it full access to everything that has happened. For longer tasks or multi-session agents, you need external memory.

The simplest form of external memory is a vector store. At the end of each session, summarise the key findings and store them as embeddings in a database such as ChromaDB or Pinecone. At the start of the next session, retrieve the most relevant summaries and inject them into the context:

import chromadb

client_db = chromadb.Client()
collection = client_db.create_collection("agent_memory")

def save_memory(content: str, session_id: str):
    collection.add(
        documents=[content],
        ids=[session_id]
    )

def retrieve_memory(query: str, n: int = 3) -> list[str]:
    results = collection.query(query_texts=[query], n_results=n)
    return results["documents"][0]

When you build an AI agent from scratch with persistent memory, you move from a stateless tool into a system that genuinely learns from experience across sessions.

Step 7: Add Observability and Safety Rails

The final step before deploying is instrumentation. Log every step of the reasoning loop: what the model decided, which tool it called, what arguments it passed, and what the tool returned. Without structured logs, debugging a failed agent run is nearly impossible.

Safety rails are equally important. Any action that is irreversible, sending an email, modifying a database record, executing a financial transaction, should route through a human confirmation step before execution. Implementing this is straightforward: before calling any write-action tool, prompt the user for explicit approval and only proceed if it is granted.

Build an AI Agent from Scratch: What Comes Next

Once you have a working agent using these seven steps, the natural progression is to add more tools, introduce parallel tool execution, implement re-ranking for memory retrieval, and explore multi-agent architectures where specialised agents collaborate on complex tasks. Each of those extensions builds directly on the foundation covered here.

The most important thing is to start. Build an AI agent from scratch on a small, bounded task. Break it deliberately. Fix it. Then extend it. That cycle of build, break, and fix is how engineering intuition develops, and intuition is what separates an AI engineer who can ship from one who can only read about it.