标签 · Observability — Glean

Recent picks

8picks · chronological

09-09

Forgotten Agent Ran 1,555 Sessions a Day and Ate My Claude Quota

The author's Claude Max quota drained in 10 minutes, and he nearly blamed a faulty meter. Digging through Claude Code's local logs, he found a forgotten background agent from a YC batch project spawning 1,555 short-lived sessions a day, with 91% of usage generated by machines rather than by him. The post explains why the limits feel broken: the 5-hour cap is a rolling window that background sessions can already fill, and every fresh session pays a cache-warmup cost roughly 12 times higher than re-reading from cache. The author turned his two-day investigation into tare, an open-source Claude Code skill that deduplicates log entries (naive counts overstate tokens by about 86%) and answers with a cause instead of a raw spreadsheet. It runs entirely locally, makes zero network calls, and can produce a scrubbed HTML usage report that can be shared without leaking prompts or file paths. Useful for anyone whose Claude Code quota keeps disappearing and for teams auditing agent-side spending.

www.kelviq.com · 8 min · Agent Engineering · Ai Tooling · Claude Code

08-07

Introducing Cloudflare Agents: Agent Tracing and Observability

Cloudflare introduces Cloudflare Agents, a unified console to deploy and manage hosted agents, launching with agent tracing. The feature adds agent-aware spans for model calls, tool executions, approval events, token usage, and supported subagent calls, overlaying existing Workers infrastructure traces (fetch, KV, D1). It is initially compatible with Think, Flue, and AI SDK, with plans to accept OpenTelemetry semantic conventions directly in Workers. Developers can replay recorded sessions to inspect full conversation context, or view execution waterfalls that show subagent delegation and the Cloudflare resources used. Traces can be exported to any OTLP destination, enabling evaluation and analytics. Pricing is based on existing Workers observability events, free during beta and then included in Workers Free/Paid plans. The feature targets teams running agents on Cloudflare who need behavior-level insight beyond traditional telemetry.

blog.cloudflare.com · 9 min · Agent Engineering · AI Agents · Cloudflare

08-03

Improving token efficiency in GitHub Agentic Workflows

GitHub's team instrumented its own fleet of Agentic Workflows through an API proxy, emitting a normalized token-usage.jsonl per run and building two daily agentic workflows—a usage Auditor and an Optimizer—that read those logs, flag anomalies, and file concrete optimization issues. The biggest wins came from pruning unused MCP tool registrations (each request can carry 10–15KB of schema overhead), replacing GitHub MCP calls with deterministic GitHub CLI invocations, and moving fixed data-gathering into pre-agentic setup steps. To compare across models they define Effective Tokens: ET = m×(1.0×I + 0.1×C + 4.0×O) with model multipliers. Of 12 production workflows, nine received optimizer changes; measured reductions were 62% for Auto-Triage Issues (109 runs), 43% for Security Guard, and 59% for Smoke Claude. One workflow regressed 5% due to workload shift, and one misconfigured bash allowlist caused a 64-turn fallback loop. The post argues for episode- and portfolio-level efficiency analysis.

github.blog · 18 min · Agent Engineering · CLI · Cost Optimization

06-28

Loop Engineering: A Technical Roadmap for an Autonomous Loop

This is a technical roadmap for building reliable autonomous loops, arguing that a loop is fundamentally different from a prompt—a prompt requires manual initiation while a loop drives itself: set a goal once, then the system finds work, executes, checks, fixes, and repeats until completion. The author emphasizes that the ceiling is set not by prompting skills but by engineering a loop that converges toward truth rather than becoming an expensive random walk. The piece provides step-by-step guidance (Step 0 through Step 7) with working code (Bash scripts), explaining the mechanics of stateless iteration (fresh context per turn to combat context rot), building a narrow relevant context with a token budget, designing incorruptible checks (external deterministic oracle + reward-hacking defense gates + adversarial judge on a different model), dual-level state persistence (human-readable STATUS.md + machine-parseable JSON), physical isolation (git worktree, container with --network none), brakes with observability (structured JSONL log, circuit breakers for stuck/repeated failures, liveness heartbeats), and nonlinear cost analysis (why stateless keeps per-iteration cost constant while stateful grows quadratically). This is aimed at production engineers building AI agent pipelines who need practical, verifiable techniques.

x.com · 18 min · Agent Engineering · Context Engineering · Loop Automation

06-26

ECC: Cross-Harness Agent Operating System for Claude Code, Cursor & Beyond

ECC is a comprehensive agent harness operating system designed to enhance multiple AI coding assistants including Claude Code, Cursor, Codex, OpenCode, and GitHub Copilot. It's not a standalone AI tool but a collection of 260+ skills, 67+ agents, persistent memory, continuous learning, cost optimization, and security auditing features. By providing unified rules, hooks, and MCP configurations across platforms, it addresses issues of inconsistent agent behavior, context loss, and inadequate security. Ideal for professional developers deeply using AI coding assistants and teams seeking standardized agent engineering practices.

github.com · 94 min · Agent Engineering · Claude Code · Context Engineering

06-15

Decomposing the agent harness into swappable workers: the iii engine architecture

Mike Piccolo argues that monolithic agent frameworks force a tradeoff by bundling the loop, tools, memory, and orchestration into one block, which long-running teams inevitably rewrite. He walks through the iii engine's production worker stack, where all thirteen harness responsibilities—credential resolution, policy checks, turn FSM, session persistence, budget tracking, etc.—are decomposed into 11 independently replaceable workers. Each worker connects to the engine via WebSocket and registers functions and triggers using a single primitive (iii.trigger()), making the harness a composable set of installable workers. The post provides a step-by-step trace of a turn through provisioning, streaming, policy-gated tool dispatch, and reactive approval wake-ups, alongside concrete examples of swapping the model catalog, adding a provider, or integrating a Slack approval surface. The core bet: an agent harness should be a slider of composable workers rather than a framework you fork. This is for backend engineers building or scaling custom agent infrastructure who are hitting the composability limits of existing frameworks.

x.com · 20 min · Agent Architecture · AI Engineering · Observability

06-08

Maple: An Open-Source Observability Platform Built on OpenTelemetry and ClickHouse

Maple is an open-source observability platform for traces, logs, and metrics, built on OpenTelemetry and ClickHouse. It features an OTLP ingest gateway with key-based auth, a chat agent, alert evaluation, and SQLite/Turso-backed dashboard persistence. The monorepo ships with Clerk or self-hosted auth modes and a full suite of CI/CD workflows for Cloudflare Workers, targeting teams that want to own their observability stack in a TypeScript-native codebase.

github.com · 9 min · ClickHouse · Cloudflare · Monorepo

06-05

OpenTelemetry Launches Blueprints Initiative to Simplify Enterprise Observability Adoption

OpenTelemetry has launched the Blueprints initiative to reduce the complexity of large-scale observability adoption. It provides prescriptive architectural patterns, operational best practices, and implementation steps for common scenarios, along with reference implementations from Adobe, Mastodon, Skyscanner, and others. The article explains how accidental complexity—fragmented pipelines, inconsistent semantic conventions, broken context propagation—emerges when organizations adopt OpenTelemetry organically without central standards. Blueprints focus on Kubernetes observability, non-Kubernetes infrastructure, and centralized telemetry platforms, aiming to operationalize telemetry consistently. The initiative reflects a broader shift toward opinionated operational frameworks in cloud-native infrastructure, targeting platform engineering, DevOps, and SRE teams grappling with observability sprawl.

www.infoq.com · 5 min · Cloud Native · Kubernetes · Observability