Forem: Harsh Mathur

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.