In the previous article, we examined the importance of software design, and how all software engineering principles have been defined to address issues rather than creating more complexity.

In this article, we will begin with one of the most significant programming paradigms known as Object Oriented Programming (OOP).

But before moving into definitions, let us examine the issue first.

🤯 The Problem

Imagine you are building a user system.

Without OOP:

const user1Name = "Ashay";
const user1Email = "ashay@gmail.com";

function loginUser1() {}
function logoutUser1() {}

Now imagine:

• 10 users
• 100 users
• admins
• customers
• sellers

Everything becomes:

• duplicated
• disconnected
• hard to manage

You have:

• data scattered everywhere
• behavior scattered everywhere

This is the core problem OOP tries to solve.

🧠 The Core Idea of OOP

OOP says:

“A real-world entity should keep its own data and behavior together.”

Example:

A User should contain:

• its own properties (name, email)
• its own capabilities (login, logout)

That combination becomes an object.

✨ What is an Object REALLY?

An object is:

A self-contained unit of state + behavior.

State = data
Behavior = actions/functions

Example:

const user = {
  name: "Ashay",
  email: "ashay@gmail.com",

  login() {
    console.log(`${this.name} logged in`);
  }
};

Here:

This is the true meaning of an object.

Then Why Do We Need Classes?

Now imagine creating 10,000 users.

You DON’T want:

const user1 = { ... }
const user2 = { ... }
const user3 = { ... }

You need a reusable structure.
That reusable structure is a class.

What is a Class REALLY?

A class is:

A factory/template that defines what an object should contain.

Example:

class User {
  name: string;
  email: string;

  constructor(name: string, email: string) {
    this.name = name;
    this.email = email;
  }

  login() {
    console.log(`${this.name} logged in`);
  }
}

Now you can create objects easily:

const user1 = new User("Ashay","a@gmail.com");
const user2 = new User("Rahul","r@gmail.com");

Deep Understanding of new

This is VERY important.

When you do:

const user1 = new User(...)

new does several things internally:

1. Creates empty object {}
2. Connects object to class prototype
3. Binds this to new object
4. Runs the constructor
5. Returns object

💡 Important Mental Model

A class is NOT the actual thing.

It is only:

• definition
• structure
• contract

The object is the real runtime entity.

Example:

Common Beginner Mistake

People think:

class User {}

means “doing OOP”.

No.

Real OOP begins when you think:

• What responsibility belongs here?
• What data should this object own?
• What should be hidden?
• How should objects communicate?
• Who controls what?

That leads to:

• Encapsulation
• Abstraction
• Polymorphism
• Dependency Injection
• SOLID principles

which we’ll cover one by one.

⏭️ What’s Next?

Now that we understand what OOP is and how classes and objects help organize state and behavior, an interesting question naturally arises especially for JavaScript developers.

If JavaScript already allows us to create objects using plain object literals and factory functions, why do we need classes at all?

Are classes simply syntactic sugar, or do they solve a different set of problems?

Before we dive into the core principles of OOP such as Encapsulation, Abstraction, Inheritance, and Polymorphism, we’ll take a small detour to explore one of the most common debates in the JavaScript ecosystem:

Factory Functions vs Classes

We’ll compare both approaches, understand their trade-offs, and discuss when each one makes sense in real-world applications.

Because before learning how to design good objects, it’s worth understanding the different ways we can create them.

Biggest thing I learned writing the AI, Ego & Regret series: I argue with myself way more than I thought.

Every post goes through the same loop:

10 PM: “This story’s fire. Gonna blow up tomorrow.”

1 AM: “Wait — did I make it clear that 450ms wasn’t just a random number?” → Scrolls back to check. Yes. OK. Move on.

Next morning: “What was I thinking? Scrap it. Rewrite from scratch.”

The cover images were the worst part. One article went through 6 different backgrounds before circling back to the first one. 45 minutes I’ll never get back.

Then there’s that one line: “It was right about yesterday — and yesterday wasn’t running anymore.” Rewrote it 11 times. My wife walked by and said, “I thought you were writing code, not poetry.”

Ben Halpern hit me with a 5-reaction combo while I was eating instant noodles. Almost choked.

Waking up at 3 AM. First instinct: check comments. Nothing. Go back to sleep. 5 minutes later: check again. Still nothing.

Writing code? I’m normal. Writing stories? I’m the guy verifying his own made-up RabbitMQ number at 1 AM.

Would I do it again? Yeah. Probably. But I’d get a better keyboard this time.

This coffee’s about to run out — and I’m not done typing yet. If these stories made you smile, chuckle, or roll your eyes, buy me a coffee and keep the keys smoking ☕🔥

Also — if you’ve got a story that’s been sitting in your head, something that made you laugh, cringe, or question every life decision that led to that moment — send it over. I’ll turn it into a story. Yours could be the next one.

No pressure. Just a keyboard that’s already warm.

The Vercel AI SDK treats agents as tool-calling loops: the model generates text or invokes tools, the SDK runs those tools, and the loop continues until the model answers or a stop condition fires.

This post builds a support triage agent that looks up customers and invoices, searches an internal knowledge base, and either opens a ticket or escalates to a human. It builds on the LLM integration with Vercel AI SDK post and focuses on multiple tools, stopWhen, and stepCountIs.

For external tools exposed over MCP instead of SDK-native tool() handlers, see the MCP server with Node.js post.

Prerequisites

• OpenAI account
• Generated API key
• Enabled billing
• Node.js version 26
• ai, @ai-sdk/openai, and zod installed (npm i ai @ai-sdk/openai zod)
• Client setup from the Vercel AI SDK integration post

Mental model – steps and the tool loop

A step is one model generation. In that step the model either:

• returns text (the loop ends), or
• returns tool calls (the SDK executes them and starts another step with the results)

Typical flow for the support triage agent: user question → model calls lookup tools (getCustomer, getInvoice, searchKnowledgeBase) → model creates a ticket or escalates → final answer. stopWhen can end the loop before or after the write tools run.

stepCountIs(5) means “stop after 5 steps” (five model generations), not five individual tool calls. A single step can include multiple parallel tool calls.

When you pass tools without stopWhen, the SDK defaults to stepCountIs(20) as a safety cap.

Support triage scenario

Example prompt:

Customer cus_1042 says they were charged twice for invoice inv_8891. What should we do?

A realistic chain:

1. getCustomer – plan tier, open ticket count
2. getInvoice – amount, status, payment IDs
3. searchKnowledgeBase – duplicate-charge and refund policy
4. createSupportTicket or escalateToHuman – write action or sentinel stop

The demo uses in-memory fixtures (customers, invoices, knowledge-base articles) so scripts run without a database.

Defining multiple tools

Register tools with tool() and Zod inputSchema. Clear description values help the model pick the right tool.

import { tool } from 'ai';
import { z } from 'zod';

const getCustomer = tool({
  description: 'Look up a customer account by ID',
  inputSchema: z.object({
    customerId: z.string().describe('Customer ID, e.g. cus_1042'),
  }),
  execute: async ({ customerId }) => {
    const customer = customers.find((item) => item.id === customerId);
    if (!customer) {
      return { found: false, customerId, error: 'Customer not found' };
    }
    return { found: true, customer };
  },
});

const getInvoice = tool({
  description: 'Look up an invoice by ID, including payment IDs and status',
  inputSchema: z.object({
    invoiceId: z.string().describe('Invoice ID, e.g. inv_8891'),
  }),
  execute: async ({ invoiceId }) => {
    const invoice = invoices.find((item) => item.id === invoiceId);
    if (!invoice) {
      return { found: false, invoiceId, error: 'Invoice not found' };
    }
    return { found: true, invoice };
  },
});

const searchKnowledgeBase = tool({
  description: 'Search internal support articles by keyword',
  inputSchema: z.object({
    query: z.string().describe('Search terms, e.g. duplicate charge refund'),
  }),
  execute: async ({ query }) => {
    // keyword match against mocked articles
    return { query, articles: matches };
  },
});

Add write tools for outcomes:

const createSupportTicket = tool({
  description: 'Create a support ticket after gathering customer and policy context',
  inputSchema: z.object({
    customerId: z.string(),
    subject: z.string().min(3),
    priority: z.enum(['low', 'medium', 'high']),
    summary: z.string().min(10),
  }),
  execute: async (input) => {
    const ticket = createTicket(input);
    return { created: true, ticket };
  },
});

const escalateToHuman = tool({
  description: 'Escalate when policy requires manual review',
  inputSchema: z.object({
    customerId: z.string(),
    reason: z.string().min(10),
    urgency: z.enum(['normal', 'high']),
  }),
  execute: async (input) => ({
    escalated: true,
    queue: input.urgency === 'high' ? 'billing-urgent' : 'billing-standard',
    ...input,
  }),
});

Return structured objects from execute. The SDK serializes them as tool results for the next step. Return explicit errors (for example { found: false, error: '...' }) so the model can recover instead of throwing.

Multi-step triage with generateText

Pass all tools and a system prompt with triage rules:

import { generateText, stepCountIs } from 'ai';

const { text, steps } = await generateText({
  model: openai('gpt-5.5'),
  system: `You are a billing support triage agent.
- Look up customer and invoice before recommending refunds.
- Search the knowledge base for policy guidance.
- Create a ticket when you can resolve within policy.
- Call escalateToHuman when manual review is required.`,
  tools: {
    getCustomer,
    getInvoice,
    searchKnowledgeBase,
    createSupportTicket,
    escalateToHuman,
  },
  stopWhen: stepCountIs(8),
  prompt:
    'Customer cus_1042 says they were charged twice for invoice inv_8891. What should we do?',
});

console.log('steps:', steps.length);
console.log(text);

Use a model that supports tool calling (same requirement as web search in the Vercel AI SDK post).

stopWhen – when the loop stops

stopWhen defines stopping conditions for the tool loop. Conditions are evaluated only when the last step contains tool results.

• A single condition stops when that condition returns true
• An array stops when any condition returns true (OR logic)
• Without stopWhen, the SDK applies stepCountIs(20)

The loop also ends naturally when the model returns text without further tool calls.

stepCountIs – cap the number of steps

stepCountIs(n) stops once steps.length reaches n. Use it on every production agent to prevent runaway loops and unbounded API cost.

Tight vs relaxed cap on the same prompt:

import { generateText, stepCountIs } from 'ai';

// Stops after 3 steps even if the model still wants more context
const capped = await generateText({
  model: openai('gpt-5.5'),
  tools: supportTools,
  stopWhen: stepCountIs(3),
  prompt: '...',
});

// Allows a fuller investigation chain
const relaxed = await generateText({
  model: openai('gpt-5.5'),
  tools: supportTools,
  stopWhen: stepCountIs(8),
  prompt: '...',
});

Combining hasToolCall with stepCountIs

hasToolCall('toolName') stops when the model invokes a specific tool in the latest step. Pair it with stepCountIs for a hard cap plus a sentinel tool:

import { generateText, stepCountIs, hasToolCall } from 'ai';

const { text, steps } = await generateText({
  model: openai('gpt-5.5'),
  system: TRIAGE_INSTRUCTIONS,
  tools: supportTools,
  stopWhen: [stepCountIs(10), hasToolCall('escalateToHuman')],
  prompt:
    'Customer cus_2201 on the starter plan reports a duplicate $190 charge on invoice inv_9104.',
});

escalateToHuman works well as a sentinel: the loop stops as soon as the model decides the case needs a human, without waiting for a final text-only step.

Inspecting steps and usage

The steps array on the result contains per-step tool calls, tool results, finish reason, and usage. Use it for debugging and cost tracking:

const { text, steps, totalUsage } = await generateText({
  model: openai('gpt-5.5'),
  tools: supportTools,
  stopWhen: stepCountIs(8),
  prompt: '...',
});

for (const [index, step] of steps.entries()) {
  console.log(`step ${index + 1}`);
  console.log('  toolCalls:', step.toolCalls?.map((c) => c.toolName));
  console.log('  usage:', step.usage);
}

console.log('totalUsage:', totalUsage);

With streamText, pass onStepFinish to log each step as it completes.

ToolLoopAgent – reusable agent definition

ToolLoopAgent wraps the same loop for reuse across scripts and API routes. It accepts the same settings as generateText (tools, stopWhen, instructions).

import { ToolLoopAgent, stepCountIs } from 'ai';

const supportTriageAgent = new ToolLoopAgent({
  model: openai('gpt-5.5'),
  instructions: TRIAGE_INSTRUCTIONS,
  tools: supportTools,
  stopWhen: stepCountIs(8),
});

const result = await supportTriageAgent.generate({
  prompt:
    'Customer cus_1042 says they were charged twice for invoice inv_8891. What should we do?',
  onStepFinish: async ({ stepNumber, usage, toolCalls }) => {
    console.log(`step ${stepNumber + 1}`, {
      tokens: usage.totalTokens,
      tools: toolCalls?.map((call) => call.toolName),
    });
  },
});

console.log(result.text);

Use .stream() for streaming. For Next.js chat UIs, see createAgentUIStreamResponse in the AI SDK agents docs.

Streaming with tools

streamText supports the same tools and stopWhen settings:

import { streamText, stepCountIs } from 'ai';

const result = streamText({
  model: openai('gpt-5.5'),
  system: TRIAGE_INSTRUCTIONS,
  tools: supportTools,
  stopWhen: stepCountIs(8),
  prompt: 'Customer cus_1042 says they were charged twice for invoice inv_8891.',
  onStepFinish: async ({ stepNumber, toolCalls }) => {
    console.error(`step ${stepNumber + 1}:`, toolCalls?.map((c) => c.toolName));
  },
});

for await (const part of result.textStream) {
  process.stdout.write(part);
}

Text streams incrementally. Tool calls run between text segments as the loop progresses.

Production notes

• Always set stopWhen – do not rely on the default stepCountIs(20) in production without monitoring
• Cost – each step is another model call; log steps or onStepFinish usage
• Tool errors – return structured errors from execute instead of throwing when the model should retry or escalate
• Instructions – keep policy rules in system / instructions, not only in the user prompt
• Same patterns elsewhere – PR review (listPRs → getChecks → submitReview) or job-fit scoring use the same loop mechanics with different tools

Demo

Runnable scripts for each section live in the vercel-ai-sdk-agents-demo folder. Get access via code demos.

Here is a number most finance teams have never calculated: the total cost of getting one new employee to full productivity in a fragmented digital environment.

Not salary. Not benefits. Not the recruiting fee. The cost of the time between their start date and the date they can operate independently at full output — including the time of every colleague who helps them get there.

For companies with consolidated, well-designed digital environments, this number runs 6 to 10 weeks of fully-loaded compensation. For companies with fragmented stacks of 8 to 12 tools that don’t integrate cleanly, it runs 14 to 20 weeks.

That gap — 4 to 10 weeks of productive capacity per hire — is one of the most expensive invisible costs in enterprise operations. And it scales directly with headcount growth.

The Calculation Most Companies Skip

The standard onboarding cost model looks like this: recruiter fee plus first-month salary plus benefits plus laptop plus software licenses. A mid-market company bringing on a $120,000 salary employee calculates something in the range of $15,000 to $20,000 in onboarding costs.

The actual cost model should look like this.

Assume a fully-loaded cost of $85 per hour for the new employee. Assume a productivity ramp that reaches 50% effectiveness at week 4 and 80% effectiveness at week 10, reaching full productivity at week 14 for a company with a moderately complex tool stack.

The opportunity cost of the ramp period — the output not produced compared to a fully productive employee — runs approximately $18,000 to $24,000 per hire at this salary level, before accounting for any manager or colleague time invested.

Now add the colleague time. A new employee in a 10-tool environment asks more questions, requires more hand-holding on where things live, and pulls more time from more experienced colleagues than a new employee in a 4-tool environment. Conservative estimate: 8 hours of senior colleague time in week one, declining to 2 hours per week by month two. Total: 40 to 50 hours of experienced-employee time per new hire.

At $85 to $120 per hour for the colleagues involved, that’s $3,400 to $6,000 in real cost that shows up nowhere in the onboarding budget.

For a company hiring 30 people per year at this salary level, the aggregate fragmentation tax on onboarding runs $650,000 to $900,000 annually. Not as a line item. As a diffuse, invisible drag on productivity that never surfaces in any report.

What Creates the Fragmentation Tax

The root cause is straightforward. Every tool in the stack is a thing a new employee must learn. Not just the interface — the conventions, the permissions model, where different types of content live, which channel is authoritative for which decisions, how the tool integrates with the other tools they’re also learning simultaneously.

A 4-tool environment has roughly 6 integration relationships to understand (each tool to each other tool). A 10-tool environment has 45. The cognitive load of navigating those relationships, before the new employee can focus on their actual job, is substantial.

The fragmentation tax compounds for roles that require cross-functional visibility. A project manager who needs to pull status from 6 different systems, synthesize it, and report upward is performing coordination labor that serves no other output. That labor is invisible because it’s embedded in their job description — but it’s directly caused by the tool architecture and would be reduced or eliminated by consolidation.

The Onboarding Efficiency Benchmark

A useful benchmark: what is your time-to-independent-operation for a new hire in a standard individual contributor role?

Not time to first task completion. Time to independent operation — the point at which the employee can navigate all required systems, locate information without asking, complete their core workflows without assistance, and contribute to cross-functional projects without needing to be oriented by colleagues.

For companies that have measured this with any precision, the results correlate strongly with tool stack complexity. Sub-8-week time-to-independence is achievable with consolidated environments. 16-plus weeks is typical for highly fragmented environments.

If you don’t know your current number, it’s worth measuring. Ask managers from three departments: how long until a new hire in this role can operate fully independently? The variance in the answers will tell you something. The averages will tell you something else.

Where This Intersects with AI Tools

The emergence of AI tools in enterprise environments adds a new dimension to this calculation.

In a consolidated AI environment — where the AI is integrated into the workspace teams already use — new employees learn the AI as part of learning the environment. The AI has access to the same context the employee is learning to navigate.

In a fragmented AI environment — where the AI is a separate tool that must be connected to other tools, prompted correctly for each use case, and maintained as another system in an already complex stack — new employees face an additional learning curve layered on top of an already demanding onboarding.

Worse, AI tools in fragmented environments often underperform for new employees specifically, because the AI lacks the organizational context that makes it useful. An AI that can’t access the CRM, the project management system, and the communication history simultaneously can’t help a new employee understand the state of a customer relationship or a project the way an integrated AI can.

The onboarding math changes when the AI has full context. The time-to-independent-operation shortens not because the tools are simpler but because the AI can answer the questions that would otherwise require a colleague’s time.

The Annual Cost of Not Fixing This

Take your current annual hiring volume. Multiply by the average fully-loaded salary of new hires. Apply a ramp efficiency factor based on your estimated time-to-independence. Add colleague time costs.

That number is the annual cost of your current fragmentation — not the total cost of fragmentation, but the portion attributable to onboarding alone.

For most mid-market companies hiring 20 to 50 people per year, this calculation produces a number large enough to justify a serious consolidation investment. The tools exist. The math usually makes the case clearly once someone does it.

The question is whether anyone has been asked to do it.

The backstory

Some time ago I adopted Quickwit at my company. For anyone who hasn’t used it: Quickwit is a search engine that runs full-text search directly on object storage (S3 or anything S3-compatible). It decouples compute from storage, so you don’t pay to keep big indexes warm to search older data. That model fits logs well.

It worked well for us, but there was a gap. Quickwit is excellent at the search engine part and leaves the rest to you by design: no end-user experience around it, and little access control. We were missing what a team needs day to day, like a usable UI, authentication, and gated ingest.

I started building that layer myself. It turned into Rootprint.

What it is

Besides the basics you’d expect for working with logs (controlling the view, seeing context around a log line, a filters panel, a histogram, severity-aware views), it adds:

• User management with Google and GitHub authentication
• Authenticated endpoints to ingest data
• Cluster stats so you can see what’s going on
• A user activity overview
• Control over sources, and more

It runs on your own infrastructure, and it’s Apache-2.0 licensed.

The stack

I wanted it light and fast, so:

• Backend: Hono running on Bun
• Frontend: Svelte 5 + SvelteKit, with Tailwind and DaisyUI

How it plugs in

Rootprint connects to any Quickwit instance through an environment variable. One caveat: it needs Quickwit 0.9+.

To get started, grab the Docker Compose file and run it:

curl -o docker-compose.yml https://docs.rootprint.io/files/docker-compose.full.yaml
docker compose up -d

The docs cover the rest of the installation options: docs.rootprint.io/install/docker-compose.

Where it’s going

I want to build a platform for logs and traces that holds up against anything else out there. Right now I’m focused on the log search experience; traces are on the roadmap but not built yet.

It’s still early and pre-1.0, so expect breaking changes between releases.

I’d love your feedback

If this sounds useful, I’d appreciate you trying it out and telling me what’s broken, confusing, or missing. Feedback and contributors are welcome.

• Source code: github.com/rootprint/rootprint
• Docs: docs.rootprint.io

Thanks for reading.

Rider 2026.2 EAP 5 is now available, bringing a faster startup flow with the new non-modal Welcome screen and quality-check hooks for AI agents.

If you’re catching up on the 2026.2 EAP cycle, be sure to check out the blog posts we’ve already published about other updates unveiled so far, including WPF Hot Reload, the finding-tests skill for AI-assisted test generation, and the earlier EAP builds.

Quality-check hooks for Claude Code and Codex

Rider 2026.2 EAP 5 introduces bundled quality-check hooks for external AI agents, starting with Claude Code and Codex. In agent workflows, a hook is an automated step that runs at a specific point in the agent’s process. Here, Rider uses a PostToolUse hook: after an agent edits a file, Rider automatically runs IDE-level validation before the agent continues.

This means agent-generated code is no longer just accepted as-is. These checks can detect code issues identified by Rider’s built-in analysis and inspections, as well as formatting inconsistencies.

Errors can block the agent from treating the task as complete, while warnings and other findings are returned as feedback the agent can use to fix its own output. The result is a tighter AI-assisted development loop where the IDE, not the agent, sets the quality bar.

Easier access to Explain with AI

The Explain with AI action is now easier to discover when you need it most: while dealing with build errors and runtime exceptions. Instead of copying diagnostics into chat or manually describing what went wrong, you can trigger an AI explanation directly from the place where Rider surfaces the problem.

For .NET developers, this is especially useful because build output often combines Roslyn diagnostics, analyzer warnings, MSBuild issues, NuGet restore problems, and multi-targeting failures. Explain with AI helps turn noisy or context-dependent errors into a clearer explanation with likely causes and next steps, so you can move from failure to fix faster.

Share your thoughts

That’s it for Rider 2026.2 EAP 5. Download the latest EAP build, try the new features for AI-assisted development, and let us know how they work in your projects.