Building Reliable Support Agents Using the Effect TypeScript Library - Michael Fester

A customer support agent interacts directly with an end user, but its next step may depend on an unreliable API or a nondeterministic model response. Add dependencies between services and workflows that run for a long time, and TypeScript’s static types alone do not describe everything that can go wrong. This is the setting at 14.ai, the AI-native customer support platform Michael Fester introduces as its co-founder and CTO.

The team uses Effect to make those operational concerns composable: type guarantees across the stack, concurrency, streaming, interruption, retries, structured errors, and dependency injection. These are pieces for building a system whose behavior remains understandable when individual operations fail. Effect also integrates with OpenTelemetry; useful observability still requires instrumentation and SDK/exporter configuration.

Adoption does not require replacing an entire application. Fester’s team chose Effect partly because it can enter an existing TypeScript codebase gradually, while supporting more stable, testable, and maintainable code as the platform grows.

Effect spans the platform rather than sitting only around model calls. The React frontend covers dashboards, the agent IDE, knowledge management, insights, analytics, and SDKs. Behind it, different interfaces serve application traffic, public integrations, data ingestion, and agent execution.

These components give the platform distinct places to handle application logic, external data, workflow execution, and persistence.

The shared contract is Effect Schema. Fester describes modeling everything with schemas to support runtime validation, encoding, decoding, typed inputs and outputs, and generated documentation. A schema describes the data; decoding or validation operations must actually interpret that description at runtime. The same contract can therefore support both TypeScript consumers and checks at external boundaries. On top of this stack, the agents operate as planners.

The agent receives user input, forms a plan, chooses an action, workflow, or sub-agent, executes it, and repeats until the task is complete. An action is a small unit of execution, such as fetching payment information or searching logs—the equivalent of a focused tool call.

A workflow packages a deterministic sequence. Canceling a subscription, for example, can require:

1. Collecting the customer’s reason.
2. Offering a retention option, if applicable.
3. Checking eligibility.
4. Performing the cancellation.

The planner can choose this workflow without having to improvise its internal procedure each time.

Sub-agents group related actions and workflows into domain modules, such as billing or log retrieval. To express the behavior inside those modules, the team built a custom DSL on Effect’s functional, pipe-based composition system. It represents branching, sequencing, retries, state transitions, and memory. The architecture combines flexible selection of what to do with explicit control over how a selected procedure proceeds.

If one LLM provider fails, the platform can fall back to another with suitable performance characteristics. Fester gives GPT-4o mini falling back to Gemini Flash 2.0 for tool calling as an example. That pairing reflects the team’s engineering judgment; the talk supplies no measured comparison of their tool-calling performance.

The retry policy carries state. The team tracks failed providers so that subsequent attempts avoid them, rather than repeatedly selecting a provider already known to have failed. That exclusion behavior belongs to their routing policy: scheduled retries alone do not automatically maintain a failed-provider set.

Response delivery has another requirement: tokens need to reach the customer while also being retained internally. The team duplicates the token stream, sending one branch directly to the user and another to storage for uses such as analytics. Effect supplies the composition tools for this arrangement; the talk does not specify its buffering or persistence guarantees.

Failure handling needs deliberate tests. The team uses dependency injection to replace live LLM providers with mocks and simulate failure scenarios without changing system internals. This makes a provider outage something the test can arrange, rather than something engineers must wait to encounter.

The development process starts with input, output, and error schemas, including their encoding and decoding behavior. Those definitions make contracts explicit and support generated documentation. Services are then composed and supplied at system entry points, keeping the choice of implementation separate from the logic that consumes it.

Effect represents required services in the type of a computation. A caller must supply those requirements before running it, while modular service implementations can be replaced or overridden. The following TypeScript example illustrates that boundary using current Effect v3 APIs, rather than reconstructing the talk’s unspecified library version. The request stays the same; supplying a different Llm implementation changes whether the computation produces a plan or a typed failure.

import { Context, Effect } from "effect";

type ProviderFailure = {
  readonly _tag: "ProviderFailure";
  readonly message: string;
};

class Llm extends Context.Tag("Llm")<
  Llm,
  {
    readonly plan: (
      request: string
    ) => Effect.Effect<string, ProviderFailure>;
  }
>() {}

const planCancellation = Effect.gen(function* () {
  const llm = yield* Llm;
  return yield* llm.plan("Cancel my subscription");
});

const available: typeof Llm.Service = {
  plan: () => Effect.succeed("Collect cancellation reason"),
};

const unavailable: typeof Llm.Service = {
  plan: () =>
    Effect.fail({
      _tag: "ProviderFailure",
      message: "Provider unavailable",
    }),
};

const planned = Effect.provideService(
  planCancellation,
  Llm,
  available
);

const failed = Effect.provideService(
  planCancellation,
  Llm,
  unavailable
);

export const scenarios = Effect.all({
  available: Effect.either(planned),
  unavailable: Effect.either(failed),
});

Both scenarios use identical consuming logic. The successful mock returns a proposed next step, not an executed cancellation; the failing mock exposes an error outcome for inspection.

Fester also reports that these guardrails help engineers who are new to TypeScript become productive. There is an initial learning curve, but once engineers understand the framework, its constraints make common mistakes and bad patterns harder to introduce.

Effect makes happy-path code look clean and explicit, but that readability can create a false sense of safety. An error caught upstream—or somewhere a reader does not see—can silently conceal an important failure. A well-typed composition still needs an intentional error policy. Engineers must understand which failures remain visible and which handlers consume them.

Dependency injection creates a related navigation problem at scale. Replacing a service is straightforward in a small example; tracing where it was provided becomes harder across multiple layers and subsystems. Modularity does not remove the need to understand the application’s service wiring.

The ecosystem itself is substantial. Its concepts and tools can overwhelm newcomers, even though Fester finds that the benefits compound once they start to click. His qualification is practical: Effect helps build predictable, resilient systems, but it does not replace engineering judgment.

The practical entry point is a single service or endpoint. Introduce Effect there, learn how its contracts and failure handling fit the application, and expand from a working boundary. A system does not need to adopt the entire ecosystem on day one.

LLM applications make this approach especially useful because nondeterministic behavior increases the value of predictable, observable surrounding systems. Effect brings functional-programming rigor into production TypeScript without requiring developers to become functional-programming purists. Start small, then let the benefits accumulate as adoption expands.