---
title: "Foundations"
canonical: "https://current.tinyfish.ai/issue/6/foundations"
publication: "TinyFish"
publisher: "TinyFish"
language: "en-US"
guide: "https://current.tinyfish.ai/llms.txt"
permalink: "https://current.tinyfish.ai/issue/6/foundations"
issue: 6
section: "foundations"
description: "Conceptual clarity earned from building at scale"
authors: ["Nora Kaplan","Rina Takahashi"]
published: 2025-12-08
updated: 2025-12-04
articles: 11
---

# TinyFish

> CURRENT is a journal about AI agents in production, for the engineering and product leaders who have to make them work. Drawing on experience building enterprise web agents, it explains why the demo succeeded and the deployment didn't, and what that means for choosing vendors, briefing the board, and avoiding mistakes others have already made.

[Read on the website](<https://current.tinyfish.ai/issue/6/foundations>)

## Issue 6 — Foundations

Conceptual clarity earned from building at scale

### What Building Teaches Builders

- [Browser Automation vs. Web Agents](<https://current.tinyfish.ai/issue/6/foundations/article/5568/markdown>) — By [Nora Kaplan](<https://current.tinyfish.ai/team/26/markdown>) · Published 2025-12-03 · Format: Field Guide

A practitioner watches months of working Puppeteer scripts shatter overnight when a website redesigns. Selectors break. The workflow dies. Teams keep making the same mistake: treating browser automation and web agents as interchangeable tools for the same job. At scale, that confusion creates systems that fail in ways you didn't anticipate, or costs that compound when volume hits. The difference isn't just technical. It determines whether your automation survives production.

### Tools & Techniques

- [When Frameworks Handle Timing for You](<https://current.tinyfish.ai/issue/6/foundations/article/5569/markdown>) — By [Rina Takahashi](<https://current.tinyfish.ai/team/25/markdown>) · Published 2025-12-03 · Format: Tools in Context

Every web automation framework decides who handles timing ambiguity: the tool or the operator. Playwright chose automatic. Click a button and the framework waits for it to become interactive without manual coordination. Less control, simpler operations. When you're maintaining automation across dozens of sites with varying loading patterns, that choice determines whether you're fixing broken waits or building new capabilities. Abstraction overhead versus maintenance burden—which cost matters more depends on what you're trying to operate.

- [When Explicit Control Reduces Overhead](<https://current.tinyfish.ai/issue/6/foundations/article/5570/markdown>) — By [Rina Takahashi](<https://current.tinyfish.ai/team/25/markdown>) · Published 2025-12-03 · Format: Tools in Context

Puppeteer exchanges 11KB of WebSocket messages with Chrome to complete a task. Playwright needs 326KB for the same operation. That 30x difference comes from architectural choices: direct protocol access versus cross-browser compatibility layers. When your content loads predictably and Chrome is your only target, you're paying overhead for capabilities you don't need. Puppeteer gives you protocol-level control and native speed. For teams running high-volume automation against stable sites, explicit coordination beats automatic handling—if your production context rewards precision over convenience.

### Pattern Recognition

- [Every Major Vendor Just Shipped Agent Orchestration](<https://current.tinyfish.ai/issue/6/foundations/article/5572/markdown>) — Published 2025-12-03

Between October and early December, Microsoft unified AutoGen and Semantic Kernel. OpenAI launched AgentKit with visual workflow builders. Google released ADK at Cloud NEXT. AWS announced AgentCore hit 2 million downloads in five months. Adopt AI shipped their framework too.

### Questions Worth Asking

The questions you ask before deployment reveal how much production experience you actually have. Beginners obsess over features and capabilities. People who've been paged at 2 AM ask different things: What breaks under real load? Who monitors this when it ships? Does staging actually resemble production?

We've learned these questions by building systems that had to survive contact with users. Not theory. Operational reality. Here are six that cut through vendor promises to what actually predicts success when you ship.

- **What Breaks When Volume Hits?** — [Source](<https://www.zenml.io/blog/the-agent-deployment-gap-why-your-llm-loop-isnt-production-ready-and-what-to-do-about-it>) — Published 2025-12-03

Tag: Demo Reality

Your demo handles ten requests beautifully. Production throws ten thousand at it and suddenly you're debugging infinite loops at midnight. What specific failure modes emerge under real load? Not theoretical edge cases. The actual ways this breaks when you can't restart it every hour.

- **Does This Become Infrastructure or Homework?** — [Source](<https://zalopay-oss.github.io/effective-engineer/09-minimize-operational-burden.html>) — Published 2025-12-03

Tag: Operational Burden

Instagram served millions with 13 engineers because they chose boring PostgreSQL. Some technologies fade into the background. Others create new on-call rotations and splinter your team's expertise. Six months in, are you still babysitting this thing or has it become invisible?

- **Does Staging Lie to You?** — [Source](<https://www.microtica.com/blog/mastering-production-deployments>) — Published 2025-12-03

Tag: Staging Fidelity

Your staging environment passes every test. Then production reveals problems you never saw coming. Does staging actually replicate production's data volumes and traffic patterns, or are you testing in fantasy conditions? The gap between them determines what surprises you at launch.

- **Can You Actually Monitor This Deploy?** — [Source](<http://guides.beanstalkapp.com/deployments/best-practices.html>) — Published 2025-12-03

Tag: Deploy Timing

Someone needs to watch production for hours after deployment. Not because you expect disaster, but because you need to catch problems fast. Can you deploy when your team is actually available to respond? Friday afternoon deploys sound convenient until something breaks.

- **Boring or Bleeding Edge?** — [Source](<https://zalopay-oss.github.io/effective-engineer/09-minimize-operational-burden.html>) — Published 2025-12-03

Tag: Technology Maturity

That shiny new framework promises everything. Proven technology has documented failure modes and available expertise when things break. What's the real cost of choosing novelty over boring reliability? The tradeoff shows up in operational predictability and how fast your team ships.

- **Do Teams Share Definitions of Ready?** — [Source](<https://www.cortex.io/post/how-to-create-a-great-production-readiness-checklist>) — Published 2025-12-03

Tag: Readiness Standards

Two-thirds of engineering leaders cite inconsistent standards as their biggest blocker. One team's "production ready" is another's "barely tested." Does your organization have shared definitions, or does every team interpret readiness differently? Inconsistency creates both risk and chaos.

### In Dialogue With Complexity

- [A Conversation with Semantic Sam, the Web's Quiet Revolutionary](<https://current.tinyfish.ai/issue/6/foundations/article/5571/markdown>) — Published 2025-12-03

We're sitting in what Semantic Sam insists on calling "a well-structured conversation space." Not a coffee shop, not an office, but somewhere with clear landmarks and proper hierarchy. Sam arrived exactly on time, which shouldn't surprise me. Punctuality is sort of their whole thing.

## Other sections in Issue 6

- [Daily Brief](<https://current.tinyfish.ai/issue/6/daily-brief/markdown>)
- [Market Pulse](<https://current.tinyfish.ai/issue/6/market-pulse/markdown>)
- [Practitioner's Corner](<https://current.tinyfish.ai/issue/6/practitioners-corner/markdown>)
- [Echoes](<https://current.tinyfish.ai/issue/6/echoes/markdown>)
- [Vision](<https://current.tinyfish.ai/issue/6/vision/markdown>)

## More

- [Publication guide](<https://current.tinyfish.ai/llms.txt>)
- [Issue archive](<https://current.tinyfish.ai/issues/markdown>)
