Contract Communication, Laravel 13.7, AI Frustrations, and Multi-Agent Systems

Creating Contractual Service Communication

TLDR: The monday.com engineering team describes how they replaced implicit, "stringly typed" service contracts with explicit, versioned JSON Schemas across their microservices architecture.

Summary: The monday.com team faced a common problem in large microservice architectures: implicit contracts that were spread across codebases and impossible to enforce. Their Reporter Service alone handles roughly 100 million daily events, making this a high-stakes refactoring. They started by using LLMs to infer initial schemas from production payloads, then iterated until achieving perfect validation rates. The schemas got centralized in a Git repository, which became the single source of truth. From there, they auto-generated TypeScript interfaces for frontend services and Go structs for backend services, and wired compatibility checks directly into CI to catch breaking changes before deployment. Each schema got assigned clear ownership, creating an internal event catalogue that reduced schema-drift incidents and even laid the groundwork for exposing some internal event streams as stable public APIs.

The key insight here is that contracts should be explicit and versioned. When you're dealing with microservices communicating via events, implicit contracts are a ticking time bomb. Someone changes a field type in one service, and somewhere downstream something breaks silently. By centralizing schemas in Git and auto-generating interfaces, they made the contract the guardrail rather than an afterthought.

Key takeaways:

• LLMs can help bootstrap schemas from existing payloads, but human iteration is still needed for edge cases
• Auto-generating TypeScript and Go interfaces from schemas keeps implementations in sync
• CI compatibility checks catch breaking changes before they reach production

Why do I care: For anyone running microservices, this is the unglamorous but essential plumbing that keeps systems from collapsing under their own complexity. The monday.com team didn't just fix their current problem—they created a foundation for APIs that could be exposed externally. That's the kind of architectural thinking that scales.

Creating Contractual Service Communication

New Laravel 13.7.0 Features

TLDR: Laravel v13.7.0 introduces interruptible jobs that respond to worker signals, new font optimization features, bulk JSON path assertions, and improved enum support.

Summary: Laravel continues its pattern of incremental but useful improvements. The Interruptible interface is the headline feature—it lets queued jobs respond to signals like SIGTERM for graceful cleanup instead of abruptly terminating mid-execution. This matters for long-running jobs that might be processing large datasets. When a worker gets a SIGTERM, the job gets a chance to clean up: close database connections, flush buffers, save state. A new WorkerInterrupted event also fires, enabling better observability into what's happening when workers receive signals.

The new @fonts Blade directive and Vite::fonts() method handle font preloading and inline style rendering directly from Vite font manifests. That's a nice DX win for teams using Vite—fewer manual link tags in your HTML.

Bulk JSON path assertions (assertJsonPaths and assertJsonMissingPaths) simplify testing multiple response values in one line. Instead of chaining multiple assertions, you can validate an entire response structure at once.

SortDirection enum support improves type safety when sorting collections. There's also LazyCollection keyBy() now accepting BackedEnum, an isLocked() method on the Lock class for checking lock state, and enum support across several manager classes.

Key takeaways:

• Interruptible jobs are essential for graceful shutdowns in long-running worker processes
• Font optimization via Blade directives reduces manual markup
• Bulk JSON path assertions make tests cleaner and more maintainable

Why do I care: The interruptible jobs feature alone is worth the upgrade for anyone running background workers. Graceful shutdowns are one of those things you don't think about until you need them—and then you really need them. The other improvements are nice-to-haves that compound over time.

Interruptible Jobs in Laravel 13.7.0

You Cannot Spell "Pain" Without AI

TLDR: A personal rant about the downsides of forced AI adoption in the tech industry, from content authenticity to performative productivity metrics.

Summary: This is a frustrated take from someone who watches the tech industry chase AI for the wrong reasons. The complaints are familiar but worth hearing: AI-generated content flooding platforms like LinkedIn makes them feel less authentic. The explosion of mediocre, useless software built just because AI makes it easy to generate code. Corporations mandating AI adoption as a KPI metric rather than focusing on actual outcomes—which is textbook Goodhart's Law: when a measure becomes a target, it stops being a good measure.

There's also the erosion of genuine human writing. When everyone has an AI assistant drafting their emails and posts, the human voice gets lost. And LLMs threaten the open web by commoditizing both content production and consumption. If every blog post sounds generated, why would anyone read blogs?

The author isn't anti-AI—it's a useful tool. But forced, performative adoption is harmful. Optimizing for "AI usage" rather than "real value created" is exactly the wrong incentive.

Key takeaways:

• Forced adoption causes backlash and inauthentic outputs
• Goodhart's Law applies: when AI usage becomes a metric, it stops being useful
• Human voice and judgment still matter in creative and technical work

Why do I care: I've seen teams adopt tools because they're trendy rather than useful. The same thing happened with blockchain, and it'll happen with AI. The question isn't whether to use AI—it's whether you're using it to solve actual problems or to check a box. This rant is a useful reminder to stay grounded.

You Cannot Spell "Pain" Without AI

Building Multi-Agent Telecom Support Systems

TLDR: A step-by-step tutorial for building multi-agent customer support systems using CopilotKit and LangGraph, with specialized agents for intent classification, customer lookup, escalation, and reply generation.

Summary: Multi-agent systems are one of the more interesting patterns emerging in AI development. This tutorial walks through building a telecom customer support system with four specialized agents. The Intent Agent classifies incoming queries—what is the customer actually asking for? The Customer Lookup Agent retrieves the customer's profile and account information. The Escalation Agent decides whether human handoff is needed, based on complexity or sentiment. The Reply Agent generates the final personalized response.

The frontend uses Next.js with CopilotKit's AG-UI protocol, useAgent, and useFrontendTool hooks to synchronize state bidirectionally between the UI and backend. The LangGraph backend defines a sequential workflow where each agent passes its output to the next, with shared state flowing through all nodes.

Key patterns worth noting: centralized React Context for state management across agents, frontend tools that agents can call to modify the UI in real-time (like showing a spinner or popping up a form), and Command.interrupt for human-in-the-loop escalation when the customer wants to talk to a person.

Key takeaways:

• Specialized agents are easier to debug and maintain than monolithic agent prompts
• State management between agents is the hard part—LangGraph handles this with shared context
• Frontend synchronization enables rich UI interactions during agent execution

Why do I care: Multi-agent architectures are becoming the standard for complex AI applications. Understanding how to coordinate agents, manage shared state, and handle escalation is essential knowledge. This tutorial provides a concrete example that's adaptable to other domains.

Build a Multi-Agent Telecom Support System with CopilotKit & LangGraph