Bilig vs. Traditional Excel APIs for AI Agents

In 2026, according to McKinsey's State of AI 2024 report, 72% of organizations now use AI in at least one business function, up from 50% in prior years. That adoption curve has exposed a stubborn gap: most of those organizations still rely on a human to open a workbook, paste in new figures, hit recalculate, and export the result. The AI pipeline stops at the spreadsheet boundary.

That boundary exists because the dominant Node.js libraries for reading and writing workbooks, specifically SheetJS and ExcelJS, were built for data extraction and file manipulation, not for live recalculation inside an autonomous process. A new runtime called Bilig is designed specifically for that missing layer: it lets an AI agent edit cells, trigger recalculation, and persist the result as JSON without ever opening a desktop application. The comparison between these two approaches is not academic. It determines whether your financial model can live inside a CI/CD pipeline or whether it stays locked behind a manual step.

SheetJS (the xlsx package) and ExcelJS are the workhorses of server-side workbook handling. Both parse .xlsx files into in-memory representations, let you read and write cell values, and serialize the result back to disk. They are mature, well-documented, and handle the full range of Office Open XML quirks.

The critical limitation: neither library recalculates. When you write a new value into a cell that feeds a chain of dependent calculations, the library stores the raw value you wrote. It does not propagate that change through the dependency graph. The cached result from the last time a human saved the file stays in place until someone opens the workbook in Excel or LibreOffice and recalculates it there.

For an AI agent running inside an n8n pipeline or a serverless function, this creates a hard constraint. The agent can read the last-known output of a financial model. It can write new inputs. But it cannot get a fresh output without a round-trip through a desktop application. In practice, teams work around this by running a headless Excel COM server on Windows, or by using a Python subprocess with openpyxl plus a separate calculation engine. Both approaches add infrastructure complexity and introduce platform dependencies that break in containerized environments.

This is not a criticism of SheetJS or ExcelJS. They solve the problem they were designed for: reading and writing file formats. Recalculation was never their scope.

Bilig takes a different position. Rather than parsing an existing file format, it implements a Node.js runtime for workbook logic: cells hold values or calculation strings, and the engine maintains a dependency graph that recalculates downstream cells whenever an upstream value changes. The state of the workbook persists as JSON, not as a binary or XML file.

For an autonomous agent, this changes the interaction model entirely. Instead of read-file, modify-value, write-file, hand-off-to-human, the agent calls a function, gets a recalculated result, and continues. The workbook becomes a stateful computation object that the agent can query and mutate programmatically, the same way it would call any other API.

The JSON persistence layer is the part that matters most for teams building on modern infrastructure. When your workbook state is a JSON document, it can live in a database, travel through a message queue, be versioned in Git, or be passed between agents as a structured payload. We have seen this pattern appear repeatedly in the automation builds we document at ForgeWorkflows: the moment data can move as JSON, it stops being a special case and starts behaving like everything else in the pipeline. You can read more about how inter-agent data contracts affect reliability in our post on why AI agents fail in production.

The honest tradeoff: Bilig's calculation engine covers a wide range of common functions, but it is not Excel. Workbooks that depend on obscure statistical functions, VBA macros, or proprietary add-ins will not recalculate correctly. If your financial model was built by an analyst who used XIRR, YIELD, or custom array functions, you need to verify coverage before committing to this approach. The library is also younger than SheetJS, which means the community surface area for edge-case debugging is smaller.

1. Recalculation fidelity

SheetJS and ExcelJS store cached values. Bilig recalculates on write. For any use case where the agent needs a fresh output after changing an input, only one of these approaches works without a human in the loop. That is not a close comparison; it is a categorical difference in what the tool can do.

2. Integration surface

Both approaches expose a JavaScript API. The difference is what that API represents. With SheetJS, you are manipulating a file format. With Bilig, you are calling into a computation engine. The second model fits naturally into the tool-calling patterns that reasoning models use when operating as agents. A model that can call setCell(sheet, row, col, value) and receive a recalculated result is operating on the spreadsheet the same way it operates on any other stateful service.

3. Persistence and portability

An .xlsx file is a portable artifact, but it is not a cloud-native one. Moving it between services requires file I/O, storage buckets, or base64 encoding. Bilig's JSON state is a first-class data structure. It moves through HTTP bodies, message queues, and database columns without conversion. For teams running n8n workflows that pass data between nodes as JSON objects, this means the workbook state can travel through the pipeline the same way any other payload does, without a separate file-handling step.

Use SheetJS or ExcelJS when your requirement is file compatibility. If you need to read a workbook an analyst sent you, extract values, and produce a report, these libraries are the right choice. They handle the full complexity of the Office Open XML specification and have years of production use behind them.

Use Bilig when your requirement is agent-driven computation. If an autonomous process needs to change an input and immediately consume the recalculated output, Bilig is the only Node.js-native option that does not require a desktop application in the loop. Financial forecasting pipelines, risk calculation services, and data verification agents that need to test multiple scenarios programmatically are the natural fit.

There is a third case worth naming: workbooks that started life in Excel and need to migrate into an agent-accessible runtime. This is harder than it sounds. The migration requires auditing every calculation string in the workbook against Bilig's supported function set, replacing unsupported functions, and validating that the recalculated outputs match the original. We have done this kind of audit work when building automation chains, and the honest answer is that it takes longer than most teams expect. Budget time for it.

I learned a version of this lesson building our first Autonomous SDR pipeline. We used a flat three-agent architecture: research, scoring, and writing all reported to a single orchestrator. It worked on five leads. At fifty, the scorer sat idle waiting on research that had nothing to do with scoring. Splitting into discrete agents with explicit handoff contracts between them cut end-to-end processing time and made each component independently testable. The same principle applies here: when you replace a monolithic Excel file with a JSON-native computation engine, you gain the ability to test each calculation path in isolation. That is worth the migration cost, but only if you do the function-coverage audit first.

For teams evaluating where spreadsheet automation fits inside a broader agent architecture, the real cost comparison between manual tasks and AI agents in 2026 is worth reading before committing to either approach.

Audit function coverage before migrating any workbook. The temptation is to migrate the whole model and discover gaps during testing. We would instead build a static analysis step that scans every cell in the source workbook, extracts the unique set of functions used, and diffs it against Bilig's supported function list before writing a single line of migration code. This surfaces blockers on day one instead of week three.

Version the JSON state in Git from the start. One of Bilig's structural advantages is that workbook state is a diff-able text artifact. Teams that treat it as a runtime object and never commit it to version control lose that advantage entirely. We would set up a Git commit hook that snapshots the JSON state after every agent-driven recalculation cycle, giving you a full audit trail of how the model changed over time.

Build the fallback path before you need it. For any workbook that contains functions Bilig does not support, we would build the Excel COM fallback path in parallel with the Bilig migration, not as an afterthought. The worst outcome is discovering an unsupported function in a production calculation at 2am with no fallback in place. The second-worst outcome is building the fallback under pressure and shipping it without testing.