Four years after LLMs entered the mainstream, the single most common mistake I see architects make is spending most of their decision energy on the model. Which frontier model? GPT or Claude or Gemini? The model choice matters — but it is one decision out of roughly fifteen, and it is far from the most consequential one.

Building an LLM-powered system in 2026 is an architecture decision made across a stack of competing frameworks, each solving a well-posed problem at a specific layer. I spent several months mapping that landscape as a practitioner — the result is a 73-page whitepaper I call the Framework Atlas. This post distils it into the five things I think every architect, engineer, and senior IT leader should know before picking a single tool.

The Stack Has a Shape

There is no single AI stack, but there is a canonical shape. Every non-trivial production LLM system — whether a support chatbot, a document search engine, or a multi-agent workflow — is a composition of six layers:

Application layer. The surface your user interacts with. LangChain is the default; Semantic Kernel is the Microsoft-native choice; CrewAI leads when the app itself is agentic.

Agent layer. When a single LLM call is not enough — when the system needs to plan, call tools, or coordinate among multiple agents — this layer provides the loop. LangGraph is the most production-grounded option in 2026.

Data / retrieval layer. The memory of your system. LlamaIndex leads on orchestration; Weaviate, Pinecone, and Chroma compete at storage, each tuned for a different operational profile.

Model layer. The foundation models themselves. This layer is increasingly commoditised. The most important design decision here is not which model you start with — it is whether you can swap it without rewriting the layers above.

Serving / inference layer. How you turn a model into an endpoint. vLLM dominates throughput-bound workloads; BentoML packages models into clean APIs for teams that want to think about models, not infrastructure.

Infrastructure layer. Kubernetes, Docker, cloud, on-prem. Every framework choice depends on where you can actually deploy.

Wrapped around all six layers are three concerns that have become non-negotiable since 2024:observability and evaluation,fine-tuning and training, andguardrails and safety. If your system design has no answer for any of these three, it is under-designed. Ignoring them does not eliminate the risk — it just defers it until something breaks in production.

The Abstraction Trap

Every framework in the atlas is catalogued against eleven attributes, but the one architects under-weight most consistently isabstraction level — how much code you write versus how much the framework decides for you.

LangChain’s high abstraction makes the first demo fast and the tenth production fix slow, because you are debugging through someone else’s default decisions. FAISS’s low abstraction costs more lines but yields fewer surprises at 3am.

The operational signal:match abstraction to team seniority. Junior teams over-value high abstraction; senior teams over-value low. A mixed team benefits from a medium default — and from making the choice explicitly rather than defaulting to whatever has the best GitHub star count.

Decision Heuristics That Actually Hold

Rather than optimising at each layer independently, the atlas maps common requirements to preferred framework combinations. These are the ones I have found most durable in practice:

Two things stand out from this table. First, LangChain and LlamaIndex are not competitors — they compose cleanly, with LangChain at the application layer and LlamaIndex at the retrieval layer. Second, local inference is no longer an edge case. Ollama plus a Llama-3-class model is a realistic production option for regulated industries where data sovereignty is a hard constraint.

Agents Moved to Production — With Guardrails

In 2023, autonomous agents were mostly demos. By 2026, they are in targeted production use: triage, routing, research synthesis. What changed is not the models — it is the frameworks.

LangGraph’s state-machine model gives agents deterministic control flow: you declare states, transitions, and retry policies explicitly. AutoGen models multi-agent systems as conversations, which makes it remarkably expressive for critique-revise loops and planner-executor separations. The practitioner heuristic:for production agents, LangGraph. For multi-agent conversations, AutoGen. For lightweight document workflows, CrewAI.

The critical note:never deploy autonomous agents in production unless the failure cost is bounded. The agent should draft; a human should approve. The pattern that ships is almost always a hybrid — autonomy where the stakes are low, escalation where they are not.

Guardrails have crossed from afterthought to critical infrastructure in the same period. Prompt injection is the new SQL injection. Every production system needs an input guard, an output guard, and a policy layer between them. The minimum viable defense in 2026 is: input guard → LLM → output guard. Anything less is operating without a seat belt.

The 2026 Outlook: Three Trends Worth Designing For

Agents are becoming the compile target. LangGraph, AutoGen, and CrewAI are converging on a common abstraction — a loop over an LLM with tool use and state. Expect a future that looks like the deep learning layer in 2018: multiple frontend frameworks, one common runtime. Design your agent layer to be swappable.

Retrieval is eating search. Elasticsearch, Postgres, and OpenSearch all ship vector indexes now; Weaviate and Pinecone ship BM25. The primitives have converged. The differentiator is no longer features — it is operational maturity and the team’s ability to run the infrastructure. Hybrid retrieval (vector + keyword) is the production-safe default.

Guardrails are becoming infrastructure. Today they are a library you bolt on. In two years they will be a runtime — prompt injection detection, PII scrubbing, and policy enforcement applied by default to every model invocation, the way CORS and auth middleware is applied to every HTTP request today. Get ahead of this by treating your guardrails layer as critical infrastructure now, not as a compliance checkbox later.

A Practitioner’s Closing Note

Frameworks age faster than architectures. The stack shape you design today — application, agent, retrieval, model, serving, infrastructure — will still be valid in three years. The individual framework boxes you fill it with probably will not be. The single most important design invariant isswappability at each layer. Make the layer interfaces clean, keep the framework-specific code thin, and you will be able to move when the landscape shifts — and it will.

The full Framework Atlas (v4.0, April 2026) covers all ten framework categories in detail, including comparison tables, maturity radars, cost and latency envelopes, and four reference architectures with working code. It is available below.

Download the Framework Atlas — Building with LLMs v4.0 (PDF)

It was a Tuesday evening. I had just taken my fourteenth screenshot of the day — a mix of Cmd+Shift+4, accidental desktop saves, files namedScreenshot 2026-05-06 at 11.43.22 PM.png scattered across my Downloads folder like confetti after a party nobody enjoyed.

I opened Finder. Forty-seven PNGs. Forty-seven. Some blurry. Some with my other windows bleeding in at the edges. Some cropped wrong because I’d sneezed mid-drag.

There had to be a better way.

The Ghost of Greenshot Past

Back in my Windows days — and I spent alot of years in Windows, running datacentres, managing Wintel estates, building VDI platforms — I hadGreenshot. If you’ve never used it, Greenshot is a free, lightweight screenshot tool that lives in your system tray. PressPrtSc, draw a box, done. Instant annotation. Instant clipboard. Instant sanity.

When I moved to macOS full-time, I expected something better. Apple builds beautiful hardware. Their software is generally excellent. And their screenshot workflow is… fine. Technically fine. But when you’re taking screenshots all day for documentation, Slack messages, architecture diagrams, and blog posts — “fine” isn’t good enough.

The native flow is:Cmd+Shift+4, drag imprecisely, file saves somewhere, you hunt for it, you paste it, you realise the crop was off, you do it again.

I Googled “Greenshot for Mac” approximately eleven times over the past year. The answers: CleanShot X (paid, subscription), Shottr (good but someone else’s decisions), or just “get used to it.”

I couldn’t get used to it. So I did what any reasonable enterprise architect does at 10pm on a Tuesday.

I decided to build it myself.

Fine. I’ll Build It.

The plan was simple: a lightweight macOS menu bar app. Lives in the status bar. One click or a hotkey and you’ve got a clean area capture, a window capture, or a full-screen grab. Auto-saves with a sensible filename. Copies to clipboard. Makes a satisfying shutter sound. Stays out of your way.

The twist: I’d build it the same way I built this blog — with Claude as my pair programmer and VS Code as the editor. I’m an architect and technologist, not a Swift developer. But that was the whole point.

I opened a new conversation, described what I wanted in plain English, and we got to work.

What AJShot Is

AJShot is a native macOS menu bar app — background-only, no Dock icon, no bloat. It sits quietly in your menu bar with a smallAJ badge. Left-click opens your last screenshot. Right-click opens the action menu.

Memory footprint: around50 MB at idle. Compare that to some Electron-based tools that idle at 300 MB just saying hello.

The right-click menu looks like this:

📷 Capture Area ⌘⇧3
🖥 Capture Window ⌘⇧4
🖥 Capture Fullscreen ⌘⇧5
─────────────────────────────
📂 Open Last Screenshot
📁 Open Screenshots Folder
─────────────────────────────
⚙️ Preferences
ℹ️ About
✕ Quit

The keyboard shortcuts are global — they work even when AJShot is in the background. You’re deep in a Zoom call, you need a quick capture, you hitCmd+Shift+3, draw the box, done. The screenshot is already in your designated folder and on your clipboard before you’ve even let go of the mouse.

Core Features

Capture Modes

Area Capture (⌘⇧3) — the workhorse. Full-screen overlay appears, cursor becomes a crosshair, you draw a box. Precise. Consistent. No more dragging the wrong direction and getting a sliver of your taskbar.

Window Capture (⌘⇧4) — click a window, capture just that window. No background bleed, no accidental desktop icons photobombing your documentation.

Fullscreen Capture (⌘⇧5) — captures everything. Supports multi-display setups with a “capture all” or “ask each time” behaviour you configure once.

Preferences That Actually Make Sense

Open Preferences and you get a clean panel with the options you’d actually want to configure:

The filename templating engine handles the sanitisation itself — no illegal characters, no trailing dots, no 240-character filenames. Files come out likeAJShot_2026-05-09_22-14-37.png. You can find them instantly. You can sort them. Your Downloads folder stays clean.

Post-Capture Flow

After every capture, AJShot runs through a quick sequence:

1. Auto-saves to your configured folder with the filename template applied
2. Copies to clipboard (if enabled) — so you can paste immediately
3. Plays the shutter sound — audio confirmation that the capture happened
4. Shows a floating thumbnail in the corner — click it to open in the editor

You can also configure the post-capture action to always ask, always edit, always save, or always copy. Once you’ve decided how you work, it remembers.

The Real Problem It Solves

Here’s the honest comparison:

The editor is where things get even more interesting. The annotation scaffolding is already built — the tools are there in the codebase: arrows, blur, text, highlights, shapes, step-number callouts. They’re not wired to the UI yet, but they’re coming. That’s the next milestone.

Tech Stack — What’s Actually Under the Hood

This is anative macOS app built entirely inSwift 5.9+, targetingmacOS 12 (Monterey) and later. The UI is a hybrid ofSwiftUI andAppKit — SwiftUI for the Preferences panel and modern views, AppKit where you need fine-grained control over system behaviour (status bar items, window management, capture overlays).

Dependencies (both bySindre Sorhus, the prolific open-source developer behind half the macOS indie tool ecosystem):

• KeyboardShortcuts — global hotkey registration that plays nicely with macOS security
• Defaults — a type-safe, SwiftUI-friendly wrapper aroundUserDefaults

Capture pipeline: usesCGPreflightScreenCaptureAccess andCGRequestScreenCaptureAccess from CoreGraphics for the permission preflight, thenScreenCaptureKit for the actual pixel capture. The permission flow has a proper retry loop — if you’ve granted permission but haven’t restarted the app, it tells you exactly that and offers a one-click restart.

Build and distribution: Swift Package Manager for dependencies, Xcode 15 for the build, and abuild-dmg.sh script that produces a signedAJShot-1.0.0.dmg for distribution. The DMG is already built. You can drag it to Applications and run it today.

Security considerations (because I work in security and these things matter):

• Screenshot folder is set to0700 permissions — only you can read it
• Individual screenshot files are0600 — same
• Filename template engine strips illegal characters and control characters at the source
• Code signing and notarization stubs are already in the README for when distribution goes wide

The architecture is clean:App →AppDelegate →StatusBarController →CaptureManager →ScreenshotStorage. Each module does one thing. TheFilenameTemplateEngine is a pure static function. TheThumbnailPresenter is decoupled from capture. Claude helped me keep it disciplined.

The Honest Struggles

No developer story is complete without the bit where things go sideways.

Screen Recording permissions nearly broke me on the first build. macOS 12+ requires explicit Screen Recording permission in System Settings, and you can’t force-trigger the dialog more than once per session. I had to build the multi-stage fallback: first launch triggers Apple’s native dialog, subsequent denials open System Settings directly, and if you’ve granted permission but not restarted, it detects that state and offers a restart button. It took longer to get that right than the actual capture code.

Swift Package Manager vs Xcode had a brief disagreement about the resource bundle forshutter.aiff. The sound file lives inAJShot/Sounds/ and has to be declared as a.process("Sounds") resource inPackage.swift. Simple when you know it. Less simple at 11pm when it just silently fails to play.

TheLaunchAtLogin manager required writing aLaunchAgent plist to~/Library/LaunchAgents/. Straightforward on paper. In practice, macOS is protective of that folder in ways that aren’t well-documented, and the error messages when something goes wrong are the kind that send you to Stack Overflow threads from 2019.

That’s the thing about building a native macOS app — the platform is powerful and the APIs are solid, but the surface area of “things that can quietly not work” is larger than you’d expect. Claude helped me navigate most of it. The frustration was real and so was the progress.

What’s Next

The annotation editor is the next major milestone — the scaffolding is already there. Arrow tool, blur tool, text tool, highlight, shapes, step-number callouts. When that’s wired up, AJShot becomes a complete Greenshot replacement for macOS: capture, annotate, save, share.

After that: GitHub release with a public DMG, code signing, notarization, and probably a product page here on CuriousBit.

If you’re a macOS user who’s been putting up with the native screenshot workflow out of habit — you don’t have to. And if you’re a developer (or aspiring one) who thinks you can’t build a native app without being a full-time Swift engineer — you can. You really can.

Try It / Share What You Use

The GitHub repo is coming soon — I’ll post the link here when it’s public. In the meantime, if you’re curious about the architecture, the Swift source, or want to follow along as the editor gets built, keep an eye on this blog.

And I’m genuinely curious:what screenshot tool do you use on macOS? Are you a CleanShot loyalist? A Shottr person? Still using the native tools and somehow thriving? Drop a note — I’d love to know.

Because the best tools are the ones built out of genuine frustration with the alternative. And I wasvery genuinely frustrated.

It started like most late-night ideas in Sydney — a MacBook, too much coffee, and a thought that refused to go away.

I wanted a tech blog. A proper one — clean, fast, with a Knowledge Base, Videos section, and a place to put thoughts on AI and enterprise tech. The problem? Zero design skills. Zero frontend experience. I know infrastructure, architecture, platforms — but CSS gives me a headache.

The Crazy Idea

Then it clicked.

What if I just described the site I wanted — in plain English — and let AI build it? Not generate a snippet. Build thewhole thing. Layouts, config, content, deployment config. Everything.

The prompt I used was simple but specific:

“Make me a clean HackerNoon-style Hugo + Tailwind blog with KB, Videos, News & Views, and About pages. Deploy-ready for Netlify.”

The Stack

The AI returned a complete project in one shot. Here’s what it chose and why it makes sense:

Hugo — a static site generator written in Go. Blazing fast builds, no database, no server to maintain. Perfect for a content blog.

Tailwind CSS — utility-first CSS. Instead of writing stylesheets, you compose classes directly in HTML. The AI could reason about it well and generate clean, consistent UI.

Netlify — one-click deployment from a GitHub repo. Push tomain, site rebuilds automatically. Free tier covers everything a personal blog needs.

GitHub — version control and the bridge between local edits and live site.

The structure it generated:content/,layouts/,assets/,static/,config.yaml,netlify.toml. Exactly what you’d expect from an experienced Hugo developer.

First Roadblock — Hit in Under 5 Minutes

Real talk — the first thing I hit was a terminal error before I’d even installed anything.zsh: command not found: brew. Homebrew wasn’t on the machine.

At first I had no idea what I was looking at.

But here’s the thing about working with AI tools — you learn to debug faster because you can askwhy something failed, not justhow to fix it. Within a few minutes I understood: Homebrew is the Mac package manager. I needed it to install Hugo. Small win — I could read what was going wrong.

Getting Hugo Running

Three commands and Hugo was running:

/bin/bash -c"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"brew install hugohugo server

The site was alive atlocalhost:1313 — navigation, article cards, dark mode toggle, the works.

The Project Structure

The generated project was clean and logical:

• content/posts/ — articles as Markdown files with YAML frontmatter
• layouts/ — Hugo HTML templates for each page type
• assets/css/ — Tailwind CSS, processed at build time
• static/ — images and files served as-is
• config.yaml — site title, menus, author, base URL
• netlify.toml — build command, publish directory, Node version

Hugo reads all frontmatter at build time and generates a completely static site. No database. No server-side rendering. No WordPress. Just fast HTML files.

Real Developer Moments

Not everything was smooth. There were genuine “how does anyone actually do this” moments — forgetting how to copy a file path in Finder, templates not updating because of Hugo’s build cache, Git authentication failing because GitHub dropped password support in 2021.

These are the moments tutorials skip. The AI handled every one of them.

Deployed. It’s Alive.

Getting it live was surprisingly painless:

1. Push the project to a GitHub repo
2. Connect the repo to Netlify
3. Set build command tonpm run build, publish directory topublic/
4. Hit deploy

Netlify pulled the code, ran Hugo, and published the static site in under 30 seconds. Everygit push from that point triggers an automatic rebuild.

What the Live Site Looks Like

The site has:

• Homepage — featured article hero, rotating video cards, Knowledge Base grid
• KB — long-form technical articles in Markdown
• Videos — auto-synced from a YouTube playlist via YouTube Data API v3. A Node.js script fetches the playlist at build time, writesvideos.json tostatic/, and the browser loads it at runtime. Add a video to YouTube, trigger a deploy, it appears on the site.
• About — a simple bio

The video section was the most technically interesting piece. No manual uploads, no embeds to maintain — just a playlist that feeds itself.

The Takeaway

This entire site — layouts, templates, CSS, YouTube integration, Git workflow, deployment pipeline — was built by someone with no frontend background. What I brought was the ability to describe what I wanted clearly, debug errors methodically, and push through the friction points.

The tools did the heavy lifting. The judgment aboutwhat to build was still mine.

Now It’s Your Turn

The stack is:Hugo + Tailwind + GitHub + Netlify + Claude. All free. All production-grade.

Start with a prompt. Describe what you want clearly. Expect errors. Fix them one at a time. Deploy early and often.

The gap between “I have an idea” and “it’s live on the internet” has never been smaller.

The full source for this site is on GitHub atibn-Battuta/AjayW_blog.