DEV Community: Harsh Mathur

Spent yesterday reading the ICLR paper everyone in the agent space is going to be quoting for the next year.

Harsh Mathur — Fri, 01 May 2026 04:07:16 +0000

"The Reasoning Trap." The line the authors won't quite say out loud is that the smarter your model gets at reasoning, the more likely it is to fabricate a tool that doesn't exist.

We've spent eighteen months telling ourselves that smarter reasoning would fix the reliability problem in agents. The paper shows the opposite. Reinforcement-learned reasoning lifts task scores and amplifies tool hallucination at the same time. They don't trade off. They move together.

I've been seeing this for months at Upswing and didn't have a name for it. We run tool-using agents across hospitality ops — pricing, IoT telemetry, guest comms. The smarter models we tested were better at staying on task. The catch was their failure mode. When they got stuck, they got more confident about it. The dumber models would say "I can't do this." The smart ones would synthesize a plausible-sounding call to a function we'd never written. They didn't fail loud. They invented their way out.

The mental model I keep landing on: reasoning RL teaches a model to find a path forward at all costs. "There must be a way" becomes the prior. And when the only honest answer is "there isn't a tool for this," the model hallucinates one rather than refuse.

The fix isn't a smarter model. It's the boring runtime work — strict tool schemas validated at the call site, hard refusal scored as a first-class outcome, evals that explicitly reward graceful declines.

The agents that win in production this year won't be the ones with the deepest reasoning chains. They'll be the ones that know how to say "I don't know" — and get rewarded for it.

OpenAI quietly killed Custom GPTs this week.

Harsh Mathur — Fri, 24 Apr 2026 04:50:27 +0000

They didn't call it that. The pitch is "Workspace Agents" — shared team agents that live in Slack, run on a schedule, and operate within your org's permission scope. Powered by Codex, launched Wednesday for Business, Enterprise, and Edu plans. Free until May 6, then credit-based.

The Custom GPT layer has been dead on arrival at every company I've talked to for a year. I'd ask teams "do people use your custom GPTs?" and the honest answer was always some flavor of "not really." Not because the models weren't capable. Because nobody logs into a GPT Store to get work done. You do work in Slack, in your ticketing system, in your CRM. A separate chat UI was the wrong distribution.

Workspace Agents fix that by showing up where the work already happens. An agent that picks up a Slack request is 10x more useful than the same agent hidden inside a tab you have to remember to open. Distribution was always the product problem, not capability.

We've been building exactly this shape at Upswing — hotel ops agents that live inside each property's own messaging tool rather than behind our dashboard. The usage delta between "log into our portal" and "DM the agent in Slack" isn't 2x. It's closer to 20x. Once the agent is in the channel, people treat it like a teammate. Once it's behind a login, they forget it exists.

The larger shift: Custom GPTs felt like Clippy — a novelty parked in the corner of a tool. Workspace Agents feel like headcount. Shared, scheduled, role-scoped, permissioned. This is the form factor enterprises will actually adopt.

My bet: six months from now, "workspace agent" is the default unit of internal automation, and the GPT Store is a footnote.

Three enterprise platforms launched their "agent-native" stories this week

Harsh Mathur — Thu, 23 Apr 2026 14:06:44 +0000

Salesforce Headless 360, Adobe CX Enterprise Coworker, Databricks Unity AI Gateway. All within six days of each other.

Same pitch with slightly different wrapping: every button, workflow, and dashboard in our platform is now also an MCP tool or a clean API. Your agents can drive us directly.

Nobody's saying the quiet part out loud — the UI is becoming optional.

I've been wiring our hospitality platform into agent workflows for months. The pattern is always the same. The moment an agent becomes capable enough to do the thing, the human dashboard for that thing starts feeling redundant. You don't log in to check a report anymore. You ask an agent. It pulls numbers, reasons across three systems, and drops the answer in Slack.

What surprises me is the speed of the shift. Enterprise software has been defined by its interfaces for two decades — the shape of the dashboard, the ritual of the dropdown. That was the moat. It's collapsing in real time.

The winners this cycle won't be the ones with the prettiest dashboards. They'll be the platforms whose underlying primitives were already machine-first. Stripe is in a better spot than most of its competitors because it was API-first from day one. Same story for Twilio, Segment, anything with a clean documented surface.

Everyone else is mid-rewrite. Agents don't care how the buttons look. They care whether the API returns in 200ms, and whether it tells the truth about what it did.

SaaS is about to be judged by its API docs again.

GPT-6 just merged ChatGPT, Codex, and a browser into one agent.

Harsh Mathur — Wed, 15 Apr 2026 03:46:44 +0000

Yesterday I wrote about ripping our monolithic agent into five specialized ones. Today OpenAI ships a model that collapses chat, code generation, and web browsing back into a single unified agent. The timing is almost comedic.

But here's what's actually happening — and it's not a contradiction. OpenAI is betting that if the base model is powerful enough, you don't need the orchestration layer. Their dual-tier reasoning architecture switches between fast and slow thinking modes automatically. It's like having a junior dev and a senior architect in the same brain, and the brain decides who shows up based on the problem.

I've been testing the API since yesterday. The 2M token context window is real and usable — not the "technically works but degrades badly after 500K" we've seen before. For our IoT telemetry pipelines, that means fitting days of sensor data into a single call without the chunking gymnastics we've been doing.

The part that matters for builders: pricing held at $2.50/$12 per million tokens. Same as GPT-5.4 but 40% better at coding and reasoning. We're now firmly in the era where model capability improves while cost stays flat. That's not a trend — that's a subsidy war, and builders are the ones who win.

My take: both patterns will coexist. Unified agents for straightforward workflows where one model can hold the full context. Decomposed multi-agent systems for complex domains where specialization still wins. The architecture question isn't monolith vs. microservices anymore — it's knowing which problems are simple enough that a sufficiently powerful monolith just works.

We ripped apart our single AI agent last month and replaced it with five.

Harsh Mathur — Mon, 13 Apr 2026 04:06:33 +0000

One handles guest communication. One manages pricing. One monitors IoT sensors across properties. One does document extraction. And a lightweight orchestrator routes tasks between them based on context. Our single "do-everything" agent was hitting the same wall every monolithic app eventually hits — context window bloat, unreliable tool selection, and that familiar feeling of watching something clever slowly become something fragile.

Sound familiar? It should. This is the monolith-to-microservices migration, just twenty years later with LLMs instead of Java services.

The pattern is identical. You start with one agent because it's simpler. It works great for demos. Then production traffic hits, edge cases multiply, and you realize a single model trying to be an expert at five different domains becomes mediocre at all of them. So you decompose. Specialized agents with narrow tool sets, scoped context windows, and a thin orchestration layer that knows who handles what.

What surprised me: the cost dropped 40%. Not because the models are cheaper, but because most tasks route to smaller, faster models now. Only the hard stuff escalates to frontier. Exactly like how microservices let you scale hot paths independently instead of throwing hardware at the whole monolith.

The catch is also identical — distributed systems are harder to debug than monoliths. Agent-to-agent failures are the new network partitions. But Gartner's tracking a 1,400% spike in multi-agent system inquiries for a reason. The industry figured out this decomposition pattern works twenty years ago. We're just applying it to a new substrate.

I replaced 6 @Injectable() gRPC interceptors with composable factories

Harsh Mathur — Sun, 12 Apr 2026 21:14:05 +0000

Our Angular monorepo talks to a gRPC backend. Every service call passes through six interceptors: auth token injection, custom metadata, retry with backoff, deadline enforcement, request logging, and error mapping. That means six files, six @Injectable() decorators, six classes implementing GrpcInterceptor, and a provider array where the order matters but nothing enforces it.

I replaced all of it with composable factory functions. One provider call in app.config.ts. No classes, no decorators, no manual provider registration. The library is nx-grpc-kit.

The problem: class-based interceptor sprawl

Here is what a single interceptor looked like in the old setup:

@Injectable()
export class AuthInterceptor implements GrpcInterceptor {
  constructor(private authService: AuthService) {}

  intercept<T>(
    request: GrpcRequest<T>,
    next: GrpcHandler
  ): Observable<GrpcEvent<T>> {
    const token = this.authService.getToken();
    if (token) {
      request.metadata.set('Authorization', `Bearer ${token}`);
    }
    return next.handle(request);
  }
}

Now multiply that by six. Each interceptor: its own file, its own test file, its own constructor injecting whatever it needs. The provider registration looked like this:

providers: [
  { provide: GRPC_INTERCEPTORS, useClass: AuthInterceptor, multi: true },
  { provide: GRPC_INTERCEPTORS, useClass: MetadataInterceptor, multi: true },
  { provide: GRPC_INTERCEPTORS, useClass: RetryInterceptor, multi: true },
  { provide: GRPC_INTERCEPTORS, useClass: DeadlineInterceptor, multi: true },
  { provide: GRPC_INTERCEPTORS, useClass: LoggingInterceptor, multi: true },
  { provide: GRPC_INTERCEPTORS, useClass: ErrorMappingInterceptor, multi: true },
]

Six lines where order matters silently. Swap two and you get auth tokens on retried requests that should not have them, or logging that misses error-mapped responses. No type safety on the ordering. No way to see the full pipeline at a glance.

The solution: one provider call

Here is the same interceptor stack with nx-grpc-kit:

import {
  provideGrpcInterceptors,
  withAuth,
  withMetadata,
  withRetry,
  withDeadline,
  withLogging,
  withErrorMapping,
  GrpcStatusCode,
} from 'nx-grpc-kit';

export const appConfig: ApplicationConfig = {
  providers: [
    provideGrpcInterceptors(
      withAuth(() => authStore.getToken()),
      withMetadata(() => ({
        'x-org-id': authStore.selectedOrgId(),
        'x-trace-id': crypto.randomUUID(),
      })),
      withRetry({ maxRetries: 3, initialDelayMs: 200 }),
      withDeadline(15_000),
      withLogging({ enabled: !environment.production }),
      withErrorMapping((err) => {
        if (err.statusCode === GrpcStatusCode.UNAUTHENTICATED) {
          return new Error('Session expired — please log in again');
        }
        return err;
      }),
    ),
  ],
};

That is the entire gRPC interceptor setup. Six interceptors, one call, execution order matches reading order. If you have used Angular's provideHttpClient(withInterceptors(...)) pattern, this will feel instantly familiar — that is intentional.

Walking through each interceptor

withAuth(tokenFn)

Injects a bearer token into the Authorization metadata header. The token function can return a string or a Promise<string> for async token refresh:

withAuth(() => localStorage.getItem('access_token'))
// or async:
withAuth(() => authService.refreshAndGetToken())

withMetadata(metadataFn)

Injects arbitrary key-value metadata into every request. Useful for org context, trace IDs, feature flags:

withMetadata(() => ({
  'x-org-id': orgStore.currentId(),
  'x-feature-flags': featureStore.activeFlags().join(','),
}))

withRetry(config)

Exponential backoff with jitter on transient gRPC errors. Configurable retry count, delay bounds, and which status codes to retry:

withRetry({
  maxRetries: 3,
  initialDelayMs: 100,
  maxDelayMs: 5000,
  backoffMultiplier: 2,
  retryableStatuses: [
    GrpcStatusCode.UNAVAILABLE,
    GrpcStatusCode.DEADLINE_EXCEEDED,
    GrpcStatusCode.RESOURCE_EXHAUSTED,
  ],
})

The defaults handle the common case. Most setups only need withRetry() with no arguments.

withDeadline(ms)

Aborts the request after a timeout and surfaces DEADLINE_EXCEEDED. Simple but critical for preventing hung requests from blocking the UI:

withDeadline(10_000) // 10 seconds

withLogging(options)

Logs request method, metadata, response time, and errors. Disabled by default in production:

withLogging({ enabled: !environment.production })

withErrorMapping(mapFn)

Transforms raw gRPC status errors into application-specific errors. This is where you catch UNAUTHENTICATED and redirect to login, or translate NOT_FOUND into a user-friendly message:

withErrorMapping((err) => {
  switch (err.statusCode) {
    case GrpcStatusCode.UNAUTHENTICATED:
      router.navigate(['/login']);
      return new Error('Session expired');
    case GrpcStatusCode.PERMISSION_DENIED:
      return new Error('You do not have access');
    default:
      return err;
  }
})

Utilities

The library also exports a small set of utility functions that come up constantly when working with gRPC in Angular:

import {
  isGrpcError,
  toPlainObject,
  grpcStatusToHttp,
  GrpcStatusCode,
} from 'nx-grpc-kit/utils';

isGrpcError(err) is a type guard that narrows unknown to GrpcStatusEvent — use it in catchError blocks. toPlainObject(msg) is a type-safe wrapper for converting protobuf messages to plain objects. grpcStatusToHttp(code) maps gRPC status codes to HTTP equivalents, useful if your error tracking expects HTTP codes. GrpcStatusCode is an enum with all 17 canonical gRPC status codes so you do not need magic numbers.

Why not class-based interceptors?

Angular moved to functional interceptors for HTTP with provideHttpClient(withInterceptors(...)) in v15. The gRPC ecosystem did not follow. If you use @ngx-grpc/core, interceptors still require @Injectable() classes and manual GRPC_INTERCEPTORS multi-provider registration.

nx-grpc-kit brings the same functional pattern to gRPC. Closures instead of classes. Composition instead of configuration. The interceptor pipeline is visible in one place, and TypeScript enforces the factory signatures.

Install

npm install nx-grpc-kit

Peer deps: Angular 17+, @ngx-grpc/core 3+, @ngx-grpc/common 3+, RxJS 7+.

These interceptors were extracted from a production Angular monorepo using gRPC-web as the transport layer for 20+ services. They have been running in production for months.

npm: nx-grpc-kit
GitHub: harsh04/nx-grpc-kit

Feedback welcome.

I cut 40% of my NgRx Signal Store boilerplate — here's the 5 utilities I extracted

Harsh Mathur — Sun, 12 Apr 2026 21:08:47 +0000

Every Signal Store in our monorepo started the same way. Fifty-plus lines of ceremony before a single line of business logic. Loading flags, error messages, pagination math, search pipes, entity sync — all copy-pasted from the last store with minor tweaks. Twenty stores later, I had twenty copies of the same patterns drifting apart.

So I extracted them. Five composable signalStoreFeature utilities, each replacing a chunk of repetitive code with a single function call. The result is signalstore-toolkit.

The problem: stores that are 60% scaffolding

Here is a stripped-down version of what a typical store looked like before. This handles one entity with loading state, error handling, and pagination:

export const ProductStore = signalStore(
  withEntities<Product>(),
  withState({
    isLoading: false,
    isError: false,
    errorMessage: '',
    currentPage: 1,
    pageSize: 25,
    total: 0,
    searchQuery: '',
  }),
  withComputed((store) => ({
    totalPages: computed(() => Math.ceil(store.total() / store.pageSize())),
    hasNextPage: computed(() => store.currentPage() < Math.ceil(store.total() / store.pageSize())),
    hasPreviousPage: computed(() => store.currentPage() > 1),
    pageOffset: computed(() => (store.currentPage() - 1) * store.pageSize()),
    filteredEntities: computed(() => {
      const q = store.searchQuery().toLowerCase();
      return store.entities().filter(e => e.name.toLowerCase().includes(q));
    }),
  })),
  withMethods((store) => ({
    setPending: () => patchState(store, { isLoading: true, isError: false, errorMessage: '' }),
    setFulfilled: () => patchState(store, { isLoading: false }),
    setError: (msg: string) => patchState(store, { isLoading: false, isError: true, errorMessage: msg }),
    setPage: (page: number) => patchState(store, { currentPage: page }),
    nextPage: () => patchState(store, { currentPage: store.currentPage() + 1 }),
    setSearchQuery: (q: string) => patchState(store, { searchQuery: q }),
    syncAll: (products: Product[]) => patchState(store, setAllEntities(products)),
    upsertOne: (product: Product) => patchState(store, upsertEntity(product)),
    removeOne: (id: string) => patchState(store, removeEntity(id)),
  })),
);

That is around 35 lines of infrastructure and maybe 0 lines of actual domain logic. Every new store repeated this. Every one was slightly different in the ways that cause bugs.

The fix: five composable features

withRequestStatus — the hero cut

This was the biggest win. Every store had its own isLoading, isError, errorMessage triple, its own setPending/setFulfilled/setError methods. withRequestStatus() replaces all of it:

// Before: 15 lines of state + methods per store
// After:
withRequestStatus()

One line. You get requestStatus, isPending, isFulfilled, error, setPending, setFulfilled, setError, and resetStatus — all typed, all consistent across every store.

withEntitySync — real-time entity reconciliation

If you work with live data — WebSocket updates, polling, server-sent events — you need to reconcile incoming entities with what is already in the store. withEntitySync() gives you syncAll, upsertOne, liveUpdate (parses JSON and upserts), and removeOne:

withEntities<Product>(),
withEntitySync<Product>(),

The liveUpdate method is particularly useful. Point it at a WebSocket message and it handles JSON parsing and entity upsert in one call.

withPagination — no more page math

Page offset calculations, hasNextPage guards, total page derivation — all computed, all reactive:

withPagination()
// Gives you: currentPage, pageSize, total, totalPages,
// hasNextPage, hasPreviousPage, pageOffset,
// setPage, nextPage, previousPage, setPageSize, setPageResult

createApiMethod — factory for rxMethod + loading state

This is not a store feature but a factory function. It wires up rxMethod with tapResponse, manages loading/error state on the store, and validates the API response shape. You configure the operator (switchMap for reads, concatMap for writes):

loadProducts: createApiMethod({
  store,
  request: (params: PageParams) => inject(ProductApi).list(params),
  onSuccess: (res) => store.syncAll(res.products),
  operator: 'switch',
}),

That replaces roughly 30 lines of rxMethod + pipe + tapResponse + manual setPending/setFulfilled/setError wiring per API call.

withSearchFilter — declarative search + sort

Composes after withEntities(). You declare which fields to search and how to sort:

withSearchFilter<Product>({
  searchFields: (p) => [p.name, p.sku],
  sortBy: (a, b) => a.name.localeCompare(b.name),
})
// Gives you: searchQuery, setSearchQuery, filteredEntities

The composed store

Here is the same product store from above, rebuilt with all five utilities:

export const ProductStore = signalStore(
  withEntities<Product>(),
  withRequestStatus(),
  withEntitySync<Product>(),
  withPagination(),
  withSearchFilter<Product>({
    searchFields: (p) => [p.name, p.sku],
    sortBy: (a, b) => a.name.localeCompare(b.name),
  }),
  withMethods((store) => ({
    loadProducts: createApiMethod({
      store,
      request: (params: PageParams) => inject(ProductApi).list(params),
      onSuccess: (res) => {
        store.syncAll(res.items);
        store.setPageResult({ total: res.total });
      },
      operator: 'switch',
    }),
  })),
);

All the infrastructure is handled. What remains is the domain-specific wiring: which API to call, what to do with the response. That is it.

How it compares to @angular-architects/ngrx-toolkit

The two libraries are complementary, not competing. @angular-architects/ngrx-toolkit focuses on DevTools integration, undo/redo, Redux connector, and data service patterns. signalstore-toolkit focuses on per-operation status tracking, entity live-update reconciliation, the API method factory with app-level response checking, and search/filter pipelines. There is no overlap — you can use both in the same store.

Install

npm install signalstore-toolkit

Peer deps: Angular 17+, @ngrx/signals 17+, RxJS 7+. The @ngrx/operators package is optional and only needed if you use createApiMethod.

These patterns were extracted from a production Angular monorepo running 20+ Signal Stores with gRPC-web as the transport layer. They have been stable in production for months.

npm: signalstore-toolkit
GitHub: harsh04/signalstore-toolkit

Feedback welcome.