In this article, we are presenting how Firetiger uses S3 and Lambda as the core primitives for the development of long-horizon agents.

Our agents run 24/7, tirelessly helping software engineer with production operations, from monitoring deployments to joining the incident response team when problems unexpectedly hit.

I've used Go for most of my career, so when we started working on Firetiger, I obviously reached out for it as the main programming language to develop our product. However, while Go has a lot of literature when it comes to developing web services, agents were really a new type of software.

here wasn't much in the ecosystem to steal from (nor in other languages), so I had to make something new, which we are open-sourcing at firetiger-oss/storage

Agent design from first principles

Agents have strong identities, but are ephemeral. They are stateful, but created on-demand. It really felt like a different type of application, one that we didn't yet have a blueprint for. I like a challenge, so the idea of designing agents from first principles was really exciting!

To match the requirements, we structured the design around two core primitives:

• Serverless Functions – AWS Lambda and friends really adapted well to the on-demand nature of agents. The compute layer needs to be elastic and isolated, so we can run an arbitrary number of sessions from of a variety of agent types without wasting time working on resource allocations. I've been in the trenches enough to know how much engineering time is required just to keep the lights on, monitor deployments, manage costs, etc... Serverless Functions package all of this behind a simple invocation API, it solves for almost all compute requirements when running long-horizon agents.
• Object Store – S3 is the most ubiquitous piece of technology in the cloud, every provider has a copy of it, and all the modern data infrastructure is built on it (e.g., Apache Iceberg, which we use heavily and we blogged about before). It is also elastic, and when it comes to storing the state of agents, it is the perfect match. Why? Because agent sessions are append-only by nature, and immutable files in S3 is a proven model which yields benefits on so many fronts: coordination, decoupling, performance, etc...

While being a durable storage layer is what S3 is most known for, it is also a lot more than that. One feature that is often overlooked is the object notification mechanism, and how it can be used as the glue between storage and compute.

With these two primitives at their core, the Firetiger agents act as pure state machines: starting a session is as simple as writing an object to S3. It triggers a notification handler, wake-up the agent that is running as a lambda function, and applies a state transition by snapshotting the mutation into another S3 object.

From theory to reality

Go has good library support for working with object store and serverless compute. Cloud providers offer SDKs, open-source communities have developed solutions like thanos-io/objstore.

However, when looking at the broader picture, there are still several features that were missing from what already existed in the open-source ecosystem.

We really needed a package with all batteries included, from storage to notifications, and including primitives like conditional atomic writes, with portability across local file systems and all major cloud providers that we deploy our software to.

When facing limitations of existing solutions, the first question is always whether to augment what already exists or start from scratch?

I like to optimize for code that I can easily customize or throw away if I don't need it anymore. When it turns out to be useful, we can always integrate back into an existing project, or open-source it!

firetiger-oss/storage was born out of this necessity, combining a modern API (like range-function iterators), with a wide feature set that remains portable across several cloud providers.

My favorite feature of the package is the S3-compatible http.Handler implementation in storage/http. We use it in several places in our web services to turn any API into an object store. For example, the artifacts that our agents produce are accessible over http as if each agent session had its own S3 bucket:

GET /v1/agents/{...}/sessions/{...}/artifacts/

<ListBucketResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <Name>firetiger-cloud</Name>
  <MaxKeys>1000</MaxKeys>
  <Contents>
    <Key>agent-audit-report.md</Key>
    <LastModified>2026-04-12T17:49:19Z</LastModified>
    <Size>34274</Size>
    <StorageClass>STANDARD</StorageClass>
  </Contents>
</ListBucketResult>

GET /v1/agents/{...}/sessions/{...}/artifacts/agent-audit-report.md

# Firetiger Agent Audit Report

- Repo: `github.com/firetiger-inc/core`
- Audit date: `2026-04-10`
- Auditor: Firetiger, Inc.
- Scope: Firetiger best-practice review only

## API setup
...

This package has been a fundamental building block of how we craft agents at Firetiger, and I'm just scratching the surface of how much we've built into it, but I'm sure it will be useful to many more people developing on object store.

Leave a ⭐️ if you like it, and reach out if you have any feedback, I'd love to hear what you think!