John P Pugliesi

This is the first post in a series about building and operating our own agent harnesses at Firetiger. In this installment, we explain why we created NXL: a declarative, domain-specific language for defining agents as structured graphs with built-in concurrency. In later posts, we’ll share what widespread

Firetiger Service Monitors automatically bootstraps best-practice observability for your entire application. Firetiger discovers your application’s architecture, breaks it down into logical Services, and then recommends Service Level Objectives that are continuously grounded in historical telemetry and behavior. Unhealthy Objectives get automatically Investigated, triaged, and escalated to you as

Firetiger helps you engineer outcomes: we build AI agents that operate and improve your software. To operate and improve software, you need “observability”: visibility into what your software is actually doing. To make observability possible, you need a data layer that lets you ask questions of your telemetry: logs, metrics,

We briefly considered prompting our agents with the classic networking playbook: polish the profile, craft a compelling personal narrative, ask for warm intros, comment “Insightful perspective” on questionable posts about politics in the workplace. Sadly, this did not help them reach your private Postgres database. In theory, Firetiger Database Agents

Today, we’re excited to announce Firetiger Database Agents (DBAs). DBAs are your always-on, expert database administrators. They connect to your database and application telemetry to proactively spot issues and performance wins, then escalate and even apply fixes before your customers notice. You can use DBAs today on Firetiger,