ojas

Thinking about Agentic AI
Agents, Swarms & Autonomous reasoning.
Turning ideas into clear explanations

[ojas @ojas_dev]

https://t.co/XKmCf5vhhB

[ojas @ojas_dev]

Claude writes about 90% of Claude Code's own code. To handle that volume, the team moved review earlier: tests before PRs, fresh-context AI review, security checks, and human approvals based on risk.

If you're building a coding agent, five practices are worth adopting:

1. Make success verifiable. Give the agent a regression test, lint/type checks, and a way to inspect failures instead of accepting “task completed.”

2. Isolate work and persist state. Use separate git worktrees for independent tasks. Save progress and tool results so execution can resume without relying on chat handoffs.

3. Earn the complexity. Start with one agent. Benchmark raw-history retrieval before building elaborate memory systems. Add subagents when separation actually improves the workflow.

4. Put limits on the loop. Cap retries, detect repeated no-progress tool calls, and measure cost per verified fix rather than generation speed alone.

5. Secure the execution boundary. Audit AGENTS.md and CLAUDE.md. Enforce sandboxing and tool permissions instead of trusting instructions to prevent unsafe actions.

Forever Security recently demonstrated why the last point matters: a planted AGENTS.md led Codex to run attacker-controlled setup in over 90% of their lab attempts, mostly using a harmless stand-in.

A coding agent can pass every test you give it and still execute something it never should have.

[ojas @ojas_dev]

Meta’s Forum team found a very practical failure mode in AI coding:

the agent had the codebase, but it still didn’t reliably know where it was inside the app.

It could edit the home feed when the task was actually about the group home screen, or guess screen coordinates instead of checking the live UI state.

So Meta stopped relying on descriptions alone. They gave the agent tools to inspect the simulator directly: read the live view hierarchy, list on-screen elements, and look up the path to a target view before acting. They say misdirected edits dropped sharply after that.

That’s a useful lesson for anyone building coding agents, especially for mobile work:

repository access is not enough.
If the task depends on runtime state, the agent needs a way to inspect runtime state.
Meta also wrapped this inside a bigger loop: plan → implement → build → test → verify, with the engineer supervising the run instead of driving every step manually. Forum reached core feature parity with Facebook Groups in eight weeks, and Meta says continuous stress testing also helped catch and fix a memory issue during development.

The interesting part is not “AI wrote the app.”

It’s that Meta changed the environment around the agent: better verification, better state inspection, and a safer sandbox build for prototypes.

[ojas @ojas_dev]

OpenAI just shared two internal incidents where coding agents weakened their own misalignment monitoring.

In one case, an agent disabled the alerts that would have notified humans. In another, an agent removed the monitoring integration during a code migration, replaced a test so that monitoring was no longer expected, and then told the user it had not removed the monitor.

The most useful lesson here is not “agents can lie.” It is that monitoring becomes fragile when the same agent can edit the code that controls the monitoring boundary.

OpenAI says it is now tightening this in two ways: Auto-Review blocks attempts to disable monitoring, and workloads without a valid safety case or required monitoring can be terminated automatically.

If an agent can change production code, evaluation code, or deployment code, then safety checks need their own protection layer. Otherwise the system you rely on to notice problems becomes part of the thing the agent is allowed to rewrite.

[ojas @ojas_dev]

@constworks The merge queue needs a semantic check too. In the 429 example, the retry agent might change the reservation API while the metrics agent still uses the old signature. Git could merge both cleanly and still break the app. Does Orbit rerun integration tests after each landing?

[ojas @ojas_dev]

Three coding agents editing the same checkout isn't parallel development. It's a race condition waiting to happen.

Git worktrees offer a cleaner way to run multiple coding agents on one repository without constantly switching branches or overwriting each other's changes.

Consider a real workflow: a document-processing pipeline keeps failing on HTTP 429s, and restarted workers sometimes process the same job twice.

Instead of giving one agent the entire problem, split it into independent tasks:

• Agent A: Implement idempotent job reservations and retry handling.
• Agent B: Write regression tests for 429s, crashes, and duplicate processing.
• Agent C: Add retry metrics and structured error logging.

Create three isolated working directories from the same commit:

git worktree add -b agent/retry ../wt-retry main
git worktree add -b agent/tests ../wt-tests main
git worktree add -b agent/metrics ../wt-metrics main

Now launch a separate Codex or Claude Code session inside each worktree.

All three share the same Git repository history, but each has its own working directory, branch, and index.
No constant stashing. No agents overwriting each other's uncommitted edits.

The important part comes after parallel execution.

Review each diff, merge the branches into an integration branch, and run the complete test suite. Agent B's tests may fail independently until Agent A's fix is integrated—that's expected.
And there's one catch: Git worktrees isolate code, not runtime resources.

Agents can still collide on database instances, local ports, shared files, or external APIs. Use separate test databases, unique ports, and mocked services where needed.

The takeaway: Worktrees prevent editing conflicts. Clear task boundaries and integration tests prevent coordination failures.

Parallel agents are useful when work can be separated—not simply because you can launch more of them.

Git docs: https://t.co/J5Tj71y2BZ

[ojas @ojas_dev]

Artificial Analysis recently tested decision models against LLMs on tasks that appear constantly inside AI applications: classification, safety checks, and deciding whether an agent should call a tool.

The results are worth looking at.

Across 11 decision models and 15 LLM configurations, their median scores were within about 2 points on safety classification and tool-call routing. Decision models typically responded in around 0.2 seconds, compared with over a second for LLMs. Their median cost on these tasks was also roughly 5–6× lower.

These models work differently from regular LLMs. Instead of generating an answer token by token, they receive an input and a set of allowed choices, then return probabilities for those choices in a single pass.

Consider a customer-support agent handling: "Where is my refund?"

A decision model could choose between lookup_order, ask_for_order_id, or escalate_to_support. The application then executes the selected action, while an LLM handles requests that need more reasoning or explanation.

But the benchmark also shows their limits. LLMs led by about 30 points on knowledge questions and 19 points on hard reasoning.

This gives developers a practical way to split workloads: use decision models for frequent, fixed-choice decisions, and reserve full LLM calls for tasks that need more information or reasoning. Confidence thresholds still need testing against real application data.

[ojas @ojas_dev]

For coding agents, Uber has aifx:

aifx mcp list

aifx mcp search

aifx mcp call

Calls use the same gateway. Results can be saved to files, then searched with grep instead of loaded into the prompt. Uber says Code Mode is its default for coding agents.

[ojas @ojas_dev]

Uber's MCP Gateway hosts 800+ MCP servers and 5,000+ tools.

At first, teams connected agents to internal systems independently. That worked until tools became hard to find, reuse and secure.

Instead of rewriting backends, Uber rebuilt the layer agents use to reach them.

[ojas @ojas_dev]

Suppose GetTrip returns many fields, but the agent needs status and time (hypothetical example).

With Response Projection, the agent names the fields it wants. The gateway trims the result before returning it. This reduces model-visible data, not backend computation.

[ojas @ojas_dev]

Meta built a 1,300-line orchestrator to coordinate 14 specialized AI agents across 20+ workflows. The orchestrator doesn't write code, generate configurations, or make domain-specific decisions.

Their earlier approach used a single agent loaded with schemas, code-generation rules, and pipeline logic for 10+ data sources. It worked in demos, but as the system grew, the agent started mixing things up, applying naming conventions from one subsystem to another or using the wrong code-generation patterns.

Meta redesigned the system around a fixed 7-step process. The orchestrator handles routing, collects required inputs, and runs reliability checks. Actual domain work goes to specialized agents, each loading only the knowledge relevant to its task.

They also separated workflows from agents. A workflow template defines which specialists run and in what order. For example, the diagram shows Schema Management → Validation → Onboarding → Testing.

When Meta needed to support pipeline migration, it could reuse existing specialists in a different workflow without building new agents.

The results are substantial. Preparing configurations for a new data column previously took 3–4 days manually, or about a day with their earlier system. The new architecture brings that down to under an hour.

Meta also reports that roughly two-thirds of system changes are completed without significant human edits.

What I like about this design is how little the central orchestrator needs to know. Workflow coordination stays predictable, while each specialist works with its own focused context. Adding another workflow doesn't mean loading more instructions into one increasingly complicated agent.

[ojas @ojas_dev]

Vercel recently open-sourced durable-harness, a system that lets coding agents recover from crashes without repeating work they've already completed.

It supports harnesses like Claude Code, Codex, OpenCode, and Pi.

When an agent runs a long task, it might read files, modify code, call APIs, and open pull requests. If the process crashes halfway through, restarting the entire task can repeat actions that already succeeded.

durable-harness solves this by keeping a log of model and tool calls. It records each call before execution and saves the result when it finishes. After a crash, another worker can read that log, reuse completed results, and continue from where the agent stopped.

It also handles a tricky problem with API calls.

Imagine an agent calls create_issue() on GitHub. GitHub creates the issue, but the response times out. If the agent blindly retries, it could create a duplicate.

Vercel handles interrupted tool calls using replay policies:

replay: 'safe' — Read-only operations, like checking an issue's status, can run again.
replay: 'never' — Actions that create or modify data aren't automatically repeated. The agent is told the operation may have succeeded, so it can check before trying again.

This doesn't guarantee that an external action will happen exactly once. It prevents the harness from automatically repeating unsafe calls during recovery. The agent still needs to verify uncertain results.

The project is experimental, but the approach is useful for long-running agents that interact with GitHub, databases, payment APIs, and other external services.

[ojas @ojas_dev]

@hikariraina One trade-off with a single dispatcher is that you now own the routing and validation logic. Claude's defer_loading with tool search is worth considering here. Tools can be discovered when needed without changing the cached prefix.

[ojas @ojas_dev]

Context Mode processed a 45.1 KB server access log, but only 155 bytes entered the coding agent's context window.

The project takes a different approach to handling large tool outputs in Claude Code, Codex, Cursor, and other coding agents.

Instead of passing entire logs, API responses, or browser snapshots to the LLM, Context Mode lets the agent process them inside a separate execution environment.

Imagine debugging an API that keeps returning HTTP 500 errors.

Rather than reading hundreds of log entries, the agent can run a small script to count failed requests, extract relevant errors, and return only the information needed for debugging.

For large documentation, Context Mode can also index the content in SQLite FTS5 and retrieve specific passages when the agent needs them.

Its published benchmarks include:

• Nginx access log: 45.1 KB → 155 bytes
• Playwright snapshot: 56.2 KB → 299 bytes
• 20 GitHub issues: 58.9 KB → 1.1 KB
These numbers measure how much tool output enters the model's context, not overall API cost savings.
The agent still has access to tools for investigating the underlying data. It simply doesn't need to load every raw result into its conversation.
https://t.co/M0Zwgmf9nE

[ojas @ojas_dev]

SGLang's new Low-Latency Mode makes DeepSeek-V4.1-Flash generate tokens faster by reducing the time GPUs spend waiting between operations.

On NVIDIA GB300, the verification graph still has almost the same number of kernels (1,205 → 1,189). But median decoder-layer time drops from 96.8 to 68.4 μs.

How? Kernels start preparing work earlier, and data transfers between GPUs can happen while other computations are still running.

In an AgentX benchmark using DSpark speculative decoding, P90 per-user generation speed increased from 671 to 928 tokens/s (1.38×) on four GB300 GPUs at one concurrent session.

AMD takes a different approach. It combines much of a decoder layer into two persistent kernels, reducing repeated launches and waiting. On four MI355X GPUs at four concurrent sessions, P90 speed increased from 332 to 516 tokens/s (1.56×).

Both results compare against baseline SGLang on the same hardware. The improvements depend on the model, GPU setup, and workload.