DEV Community: Orwa Mahmoud

Inside AdaptTable’s AI layer: discovery, context, and capabilities

Orwa Mahmoud — Sat, 03 Oct 2026 15:01:33 +0000

In Part 3, I introduced the optional AI layer in AdaptTable v3. This article goes deeper into how to connect it, how an agent discovers the table’s capabilities, how context is selected, and how an application can extend that capability set without building a separate AI tool layer for the table.

For developers building an agentic CRM, dashboard, admin panel, or SaaS application, the starting point is the normal table configuration. Connect the optional AI layer and supply your model or agent connection. AdaptTable supplies the supported table capabilities and their execution path, so you do not have to implement each table action again as a separate agent tool.

One configuration for the React data table and the agent

Consider an orders table. Its columns define order numbers, statuses, customers, and amounts. Its features enable filtering, sorting, grouping, and editing. Its callbacks connect changes to your application.

A person can operate that table through its controls. An agent can operate it through the capabilities exposed by its AI session.

For example, a connected agent can translate:

Show pending orders, group them by customer, and sort by amount.

into the supported filtering, grouping, and sorting actions on that table. Those actions reuse the configured table behavior.

A read-only report and an editable admin screen therefore expose different capabilities, even when they use the same library.

If editing is disabled, there are no editing capabilities or instructions taking up context. The same goes for other disabled features. You spend context on the capabilities enabled on that table, not everything AdaptTable supports.

AdaptTable’s AI capabilities include search, filtering, sorting, pagination, grouping, aggregation configuration, selection, column management, pinning, saved views, exports, and configured write operations. Existing row and bulk actions can also contribute capabilities. See the AI capabilities guide for details.

The table configuration is the shared starting point for the interface and the agent.

The live session is the connection point

The architecture separates the configured AdaptTable instance, the live agent session, and the integration used to connect your model or agent:

Your model or agent
        ↕
Choose an integration path
├── AdaptTable HTTP protocol
│   └── JSON response or streamed SSE
├── AI SDK adapter
│   └── AI SDK tool/message stream format
├── AG-UI adapter
│   └── AG-UI events, state, and tool calls
└── Custom agent integration
    └── Your agent maps its actions to the AgentSession
        ↕
Live AgentSession
├── catalog()   → discover available capabilities
├── describe()  → load detailed guidance when needed
└── execute()   → run AdaptTable actions
        ↕
Your configured AdaptTable
├── Features and columns
├── Current state and data source
└── Application callbacks

AdaptTable supports several ways to connect a model or agent to the same live AgentSession: the AdaptTable HTTP protocol, the AI SDK adapter, the AG-UI adapter, or a custom integration that maps your own agent to the session.

Each option changes how the agent connection is wired, while capability discovery and execution still go through the same AgentSession.

The connections are bidirectional: table context goes to the agent, proposed actions come back, and execution results can be returned when the workflow needs them.

@adapttable/ai supplies the provider-neutral session and executor. @adapttable/ai-react connects them to the live React table.

Where the session comes from

In React, tableAgent(...) is added to the table’s features prop. Its bridge.attach callback supplies the live session.

For an existing React AdaptTable instance, first receive that session in component state:

import { useState } from "react";
import type { AgentSession } from "@adapttable/ai";

// Inside your existing table component:
const [session, setSession] = useState<AgentSession | null>(null);

Then add the AI feature alongside the table features you already use. This example keeps an existing filtering feature:

import { tableAgent } from "@adapttable/ai-react";

// In your existing component's JSX:
<DataTable
  data={rows}
  columns={columns}
  rowKey="id"
  features={[
    filters([]),
    tableAgent({
      tableId: "orders",
      bridge: { attach: setSession },
    }),
  ]}
/>

Here, DataTable, filters, rows, and columns belong to the existing table setup. Keep its other feature entries too.

Adding tableAgent(...) to this table attaches the integration. tableId: "orders" assigns a stable identity used in the AI contract; it does not look up an HTML element. You assign that identity here rather than defining a matching DOM ID elsewhere.

The session received by setSession is what the assistant or custom agent integration uses. Your existing data, columns, and callbacks remain in place. AI access settings can further restrict what the session exposes, as we’ll see below.

The AI setup guide contains the complete assistant wiring. The important architectural boundary is that the agent connects to a live table session.

Capability discovery and progressive disclosure

The session separates discovering an operation, understanding it, and executing it.

Session method	What it provides
`catalog()`	Available capability keys and short summaries.
`describe(key)`	Detailed instructions, accepted arguments, and result schema for a capability.
`execute(...)`	Execution through the table integration, with a structured result.

Available capability catalog
├── view.setPage     → Change the page
├── view.setFilters  → Apply filters
└── edit.cells       → Edit cell values
              │
User: "Mark order ORD-1042 as reviewed"
              │
              ▼
Is the edit.cells guide in context?
              │
        ┌─────┴─────┐
       yes          no
        │            │
        │            ▼
        │     describe("edit.cells")
        │     (arguments, row references,
        │      write guidance)
        │            │
        └─────┬──────┘
              ▼
Agent constructs the edit action

catalog() is derived from the live AdaptTable instance. Its enabled features, columns, source capabilities, configured actions and callbacks, and AI access settings determine which capabilities appear. If that configuration changes, the catalog reflects what the table can currently support and permit.

The distinction between catalog() and describe(...) becomes useful when an AdaptTable instance exposes many capabilities.

catalog() gives the agent every capability currently available on that AdaptTable instance, with its key and a short summary. The agent therefore knows what it can do without needing the full instructions for every operation in its context.

The catalog does not need to carry every capability’s full instructions. Each available capability remains visible by key and short summary, while its detailed guide and input schema can be supplied separately.

If the user asks for an operation whose detailed guidance is not already in the model’s context, the agent already knows that capability exists and knows its key from the catalog. It can request that key’s guidance, and the integration retrieves it through describe(...).

This separation keeps capability discovery lightweight without hiding available operations from the agent.

The same general pattern appears in Agent Skills, where a skill’s name and description support discovery and its full instructions are loaded when relevant. AdaptTable applies that pattern to capability guides and schemas; the analogy does not mean table capabilities are SKILL.md files.

Custom capabilities use the same session

The catalog is not limited to AdaptTable’s built-in operations. A developer can expose application-specific logic to the agent by registering a custom capability with its own:

key — the stable capability identifier, such as orders.archive.
summary — the short description that appears in catalog().
guide — the detailed instructions the agent receives through describe(...).
input schema — the arguments the agent is allowed to send.
output schema — the structured result the capability returns.
isEnabled rule — whether the capability is available for the current table state and policy.
execute handler — the application code that actually performs the operation.

For example, an orders application can expose an orders.archive operation:

import type { AgentCapabilityDefinition } from "@adapttable/ai";

const archiveInput = {
  type: "object",
  properties: {
    rowKey: { type: "string" },
  },
  required: ["rowKey"],
  additionalProperties: false,
} as const;

const archiveOutput = {
  type: "object",
  properties: {
    archived: { type: "boolean" },
  },
  required: ["archived"],
  additionalProperties: false,
} as const;

const archive: AgentCapabilityDefinition = {
  key: "orders.archive",
  summary: "Archive an order.",
  kind: "write",
  guide: {
    guide: "Archive an inactive order by its stable row key.",
    input: archiveInput,
    output: archiveOutput,
  },
  isEnabled: (observation) =>
    observation.writePolicy === "allow",
  execute: async (_context, args) => {
    await archiveOrder((args as { rowKey: string }).rowKey);
    return { archived: true };
  },
};

tableAgent({
  tableId: "orders",
  capabilities: [archive],
  commit: "immediate",
  approval: "writes",
  bridge: { attach: setSession },
});

This archive handler performs the operation directly and does not support staging. Here, commit: "immediate" applies to all AI writes on this table, while approval: "writes" keeps human approval enabled. Approved writes execute without waiting for a separate Save step.

When enabled, orders.archive appears in catalog() like any other capability. describe("orders.archive") exposes its detailed guide and schemas, and execution still goes through the live session.

Because this capability is declared as a write, it also enters the same governance path as built-in write capabilities: write policy, commit compatibility, approval when required, revision and permission checks, and only then the application handler.

Custom capabilities therefore extend what the agent can do without creating a second execution architecture beside the table.

Full and compact context

AdaptTable offers two profiles for deciding how much capability guidance is sent to the model up front.

full is the default. It has no soft token budget unless the application supplies one. Enabled capability guides and input schemas, together with the available column descriptions, are therefore included up front rather than intentionally deferred for compactness.

compact uses a soft token budget. The default is 1,000 estimated tokens, and the application can override it with tokenBudget. The budget is a selection target, not permission to cut a schema or guide in half.

How the context builder selects what travels up front

Both profiles use the same context builder. What changes is the budget and therefore how much detail is selected before discovery is needed.

The builder keeps the permitted contract intact while deciding how much descriptive detail travels with it.

Available capability guide
            │
            ▼
Required up front?
            │
      ┌─────┴─────┐
     yes          no
      │            │
      │            ▼
      │      Selection order
      │      ├── priority
      │      └── remaining capabilities
      │            │
      │            ▼
      │      Fits soft token budget?
      │        ┌───┴───┐
      │       yes      no
      │        │        │
      │        │        ▼
      │        │   Defer guide + input schema
      │        │   reason: budget
      │        │
      └────┬───┘
           ▼
Would attaching guide + input schema
exceed the 128,000-byte hard limit?
           │
      ┌────┴────┐
     no        yes
      │          │
      ▼          ▼
Attach guide   Defer guide + input schema
+ input schema reason: hard-limit

In every case:
capability key + summary remain discoverable

The selection rules are explicit:

include marks a capability guide as required up front. It may take the context over the soft token target; only the hard capability-context size limit can still defer it.
Compact mode also treats its built-in common operations as required up front: filtering, sorting, search, pagination, row reads, grouping, and aggregation configuration.
Guides loaded through discovery are remembered for the same connection and contract version. If the context is built again under that same contract, those previously requested guides are considered first and treated as required against the soft budget, avoiding another discovery round for the same instructions.
priority is the application’s ordering preference for the remaining guides. It moves those guides earlier in selection, but does not guarantee that they will fit.
After that, the remaining capabilities are considered in deterministic registry order.
Optional guides are included only when their complete guide and input schema fit within the remaining soft token budget. If they do not fit, the guide is deferred while the capability key and short summary remain available for discovery.

The selector handles required guides before optional ones:

Required guides
├── previously requested through discovery
├── built-in common compact operations
└── guides named in `include`
        │
        ▼
Optional guides
├── application `priority`
└── remaining capabilities in deterministic registry order
        │
        ▼
Fit optional guides within
the remaining soft token budget

include and priority therefore serve different purposes: include makes a guide required against the soft budget, while priority only changes how early an optional guide is considered.

The soft budget is token-based. Without a tokenizer supplied by the application, AdaptTable estimates tokens; an application can provide its own estimateTokens implementation when it wants model-specific counting.

Capability guide attachment also has a separate hard ceiling of 128,000 UTF-8 bytes. A guide is atomic: if attaching its guide and input schema would cross that ceiling, the guide is deferred with a hard-limit reason rather than truncated, even if it would otherwise be required up front.

This means the application can force important guides up front with include, influence which optional guides are most likely to fit with priority, and control the soft target with tokenBudget

For example:

import { assistantHttpTransport } from "@adapttable/ai/http";

const transport = assistantHttpTransport({
  endpoint: "/api/agent",
  context: {
    profile: "compact",
    tokenBudget: 1600,
    include: ["edit.cells"],
    priority: ["export.run"],
  },
});

Here, edit.cells is required up front, while export.run is only considered earlier than the normal remaining capabilities.

The HTTP discovery path can retrieve multiple missing guides together and cache them for the connection and contract version. It does not require a separate discovery exchange for every capability.

Deferred guidance does not mean a disabled capability. The operation remains available; only its detailed instructions were left out of the initial context.

The trade-off is between more initial context and additional discovery exchanges. The context-selection implementation exposes the budget and selection information so the application can log it, feed it into observability, debug selection behavior, and tune the context strategy.

Neither profile grants additional permissions. Context selection decides how much to explain, not which actions the agent is allowed to perform.

What the agent knows about the table

There are three different kinds of information involved: the table’s contract, its current view, and its row data.

Agent context
├── Contract
│   ├── Available capabilities
│   ├── Column metadata
│   ├── Access settings and limits
│   └── Write / approval / commit policies
│
├── Current view
│   ├── Page and page size
│   ├── Search and sorting
│   ├── Grouping
│   └── Filter state
│
└── Row data
    └── Read only when the task needs it,
        through bounded rows.read

The contract: what this table supports

The contract describes available capabilities, column metadata, access settings, limits, and execution policies.

For the orders table, it can explain which columns are writable, which filters exist, and which operations are supported. Column descriptions can also communicate business meaning, units, or storage conventions that are not obvious from the column type alone.

amount: {
  type: "number",
  ai: {
    description: "Order total stored in cents.",
  },
}

The model can then interpret 12500 as $125.00 instead of assuming the stored value is already in dollars.

Column descriptions and examples can be deferred to save context without removing the column itself from the contract.

The contract changes when something structural changes: for example, the available capabilities, relevant column metadata, or execution policy.

The view: where the table is now

The view describes the current page, sorting, filters, grouping, and other relevant state.

A user changing the page does not necessarily change the capability contract. Keeping these separate lets an integration update the current view without treating every interaction as a completely different set of tools.

This keeps the agent grounded in the same current view the user is working with: page, search, sorting, grouping, and filters are sent from the live table state. If that view changes while the agent is reasoning, the view revision lets execution detect that the plan is stale instead of applying it against a different table state.

That distinction also matters for HTTP delivery: a relatively stable contract can be reused while the current view still travels fresh with each turn.

Row data: what the task actually needs to read

Publishing the capability catalog does not automatically send the whole dataset to the model.

When the task needs cell values, rows.read provides bounded reads under the table’s readable-column and source-scope rules. An application can also explicitly opt columns into limited example sampling; that is a separate data read, not an automatic dump of table rows.

This matters with server-side pagination. Reading one loaded page does not mean the agent has inspected every matching record in the database. Broader reads depend on what the configured data source supports.

The agent context documentation describes the contract/view separation, column guidance, and optional sampling.

AI access can differ from the table interface

An operation may be useful to a person using the table but inappropriate for the agent on that screen.

For example, the orders table might retain its export and delete controls while excluding those capabilities from AI. It might also display internal notes to the user without exposing their cell values through the AI session.

These options go in the same tableAgent(...) configuration:

// Access-setting excerpt from the existing tableAgent entry:
tableAgent({
  tableId: "orders",
  bridge: { attach: setSession },
  excludeCapabilities: ["export.run", "rows.delete"],
  columns: {
    internalNotes: {
      readable: false,
      writable: false,
    },
  },
});

excludeCapabilities removes those keys from the agent’s catalog and execution path. The table’s normal controls are unaffected.

The column settings prevent the AI session from reading or editing internalNotes cell values.

For an individual row or bulk action, ai: false on its definition excludes that action from AI while preserving its normal table behavior.

For filters, ai: false excludes that specific filter from AI entirely, so the agent does not know about or use it.

const rowActions = [
  {
    key: "refund",
    label: "Refund",
    ai: false,
    onClick: refundOrder,
  },
];

const filters = [
  {
    key: "internalFlag",
    label: "Internal flag",
    ai: false,
  },
];

Here, refund is still available to the user but not to AI, and internalFlag is not exposed to the agent at all.

To remove filtering entirely instead of excluding individual filters, use:

tableAgent({
  tableId: "orders",
  excludeCapabilities: ["view.setFilters"],
});

These access controls are separate from approval and saving. Availability answers whether the agent can use an operation. Approval answers whether a person must confirm it. Commit behavior determines what happens after it is accepted.

Where this leaves the architecture

The result is one configured AdaptTable instance that can expose a live AI contract without duplicating the table into a second set of hand-written tools.

The session tells an agent what the table can do. The catalog keeps those capabilities discoverable. Detailed guidance can be supplied progressively. The context builder makes the upfront selection explicit. And applications can add their own governed capabilities when the built-in operations are not enough.

Try the live AI demo or explore the source on GitHub.

The next article follows the other half of the path: what happens after the agent decides to act — revisions, idempotency, approvals, staged and immediate writes, execution receipts, HTTP contract pinning, streaming, and existing agent stacks.

Next in Building AdaptTable: From AI intent to safe table execution in AdaptTable.

AdaptTable v3 is live: a framework-neutral engine, smaller feature imports, and optional AI

Orwa Mahmoud — Sun, 20 Sep 2026 13:16:09 +0000

In my last AdaptTable update, I wrote about how much the project had grown by v2.9.

By then, AdaptTable already had grouping, tree data, pivoting, editing, exports, virtualization, responsive layouts, and a lot more.

That growth created a different problem.

I didn't want every table to carry the weight of every feature, and I didn't want React itself to define the engine underneath the library.

v3 is the release where I cleaned that up.

React is no longer the engine

AdaptTable is still built for React developers today, and the same idea remains: use the UI kit already in your project instead of bringing in a table with a completely different look and feel.

What changed is the architecture underneath it.

Framework-neutral models and table operations now live in @adapttable/core.

React-specific hooks and subscriptions live in @adapttable/react.

The adapters then handle the actual UI for Mantine, MUI, Chakra UI, Ant Design, Radix Themes, Base UI, shadcn/ui, and the unstyled/Tailwind route.

Roughly:

@adapttable/core
        ↓
@adapttable/react
        ↓
Mantine / MUI / Chakra / Ant / Radix / Base UI / shadcn / unstyled

The engine no longer needs to know how React subscribes to state, while the React layer only handles the React-specific binding around the table logic.

It gives AdaptTable a cleaner foundation for other framework bindings later.

Vue and Angular bindings are not part of v3. The engine is ready for that direction, but React is still the shipped framework binding today.

Optional features are actually optional now

v2 had already started moving features behind separate import paths.

But there was still a problem.

A feature can have its own public subpath and still end up in the main dependency graph if the root DataTable imports its implementation internally.

So an import can look modular without really being a bundle boundary.

In v3, the old feature-enabling props are replaced by feature factories.

A basic table can stay basic:

import { DataTable } from "@adapttable/mantine";

<DataTable
  data={rows}
  columns={columns}
  rowKey={(row) => row.id}
/>;

If that table needs grouping, it adds grouping:

import { DataTable } from "@adapttable/mantine";
import { grouping } from "@adapttable/mantine/grouping";

<DataTable
  data={rows}
  columns={columns}
  rowKey={(row) => row.id}
  features={[grouping("team")]}
/>;

The same approach is used for editing, virtualization, row reordering, column menus and other optional features.

For applications that want the common controls together, there is still a convenient preset:

import { standardFeatures } from "@adapttable/mantine/preset";

So you can start with the preset for the common setup, or import individual features when you want a narrower table.

In practice, the bundle cost follows the features your table actually uses.

AI follows the same AdaptTable philosophy

v3 also adds @adapttable/ai.

I didn't want AI support to mean choosing a specific model provider, SDK or agent architecture just to use the table.

The AI layer is separate from the normal table packages.

A table exposes only the operations it actually supports. If editing is not enabled, the agent does not get editing tools. If a write needs approval or an application callback, it still has to go through that path.

The application keeps control of authorization, validation, and persistence.

There is a ready-made assistant UI, but it is optional. The same capabilities can also be connected to an existing chat interface or agent runtime.

This follows the same idea as the UI adapters: AdaptTable should work with the stack already used by the application.

AdaptTable has its own provider-neutral session and capability contract, and it also ships adapters for AI SDK and AG-UI, alongside integrations for OpenAI tools, MCP, and lower-level JSON.

So an application can keep its existing provider, backend, and agent setup instead of rebuilding around AdaptTable.

And like the rest of v3, AI is opt-in. If you never import the AI packages, the normal table does not depend on them.

I'll cover capability discovery, revisions, approvals, execution results, and the boundary between the agent, table, and application in a separate post.

Moving from v2

v3 is a major release, so there are breaking changes.

React-specific hooks that previously came from @adapttable/core move to @adapttable/react.

The old feature-enabling props are replaced by feature factories.

Deprecated routes and aliases that were being kept around for compatibility are removed.

The CLI can help with supported import migrations, but I would still review application behavior after upgrading. A codemod can move an import; it can't decide how your application wants editing, persistence, or a custom feature to behave.

The v2 → v3 migration guide covers the changes and replacements.

AdaptTable remains MIT licensed.

You can try the live demo, read the documentation or browse the source on GitHub.

From v1 to v2.9: how AdaptTable grew into a full React data-grid toolkit

Orwa Mahmoud — Thu, 03 Sep 2026 19:44:50 +0000

Back in July I wrote the first post about AdaptTable.

The project was still v1, and the idea was fairly focused: one table engine that could sit behind the UI kit a React project already uses.

MUI project? Use the MUI adapter.

Mantine? Use Mantine.

Ant Design, Chakra, Radix, shadcn, Base UI, or your own Tailwind styles all sit on the same engine too.

That model is still there. The engine behind it has just grown a lot since then.

The core is at v2.9 now.

GitHub · Live demo · Getting started

The feature set got much bigger

The first release already covered the things I kept needing in application tables: sorting, filtering, pagination, URL state, saved views, column controls, server-side data, mobile layouts, selection, and row/card virtualization.

Since then I've added quite a bit on top of that.

Grouping now supports multiple levels and aggregates.

There is tree data, pivot tables, formula/computed columns, and sparklines.

The editing side grew a lot too.

AdaptTable now has keyboard cell navigation, rectangular range selection, clipboard copy/paste, cut, fill handle behavior, and edit history.

Editing can happen at cell level, row level, or as batched changes. There is validation, async validation, dirty-state tracking, and conflict handling for cases where live data changes while somebody is editing.

Rows have more control now as well:

Row reordering
Top and bottom row pinning
Row and column spanning
Full-width rows
Custom row heights and styling
Tree and nested structures

Export also moved beyond CSV and print, with XLSX and PDF support now available.

Keeping the feature API manageable

As the feature set grew, I wanted a basic table to stay basic.

A normal table can still look like this:

<DataTable
  data={rows}
  columns={columns}
  rowKey={(row) => row.id}
/>

v2 introduced a feature composition API for optional behavior.

For example, row reordering can be added through its own entry point:

import { DataTable } from "@adapttable/mantine";
import { rowReorder } from "@adapttable/mantine/row-reorder";

<DataTable
  data={rows}
  columns={columns}
  rowKey={(row) => row.id}
  features={[
    rowReorder(handleReorder)
  ]}
/>

Grouping, editing, virtualization, cell navigation, saved views, and other features follow the same direction.

There is also a public TableFeature API behind this. A feature can register its own editors, aggregators, commands, filters, menu items, panels, and other extensions through the same feature system.

That gives me a cleaner way to keep expanding AdaptTable without turning every new capability into another permanent special case inside DataTable.

Some of the heavier code is already separate

I also started splitting heavier capabilities into their own entry points instead of exporting everything from the main core package.

Today the core has separate entries for things like:

@adapttable/core/xlsx
@adapttable/core/pdf
@adapttable/core/formula
@adapttable/core/pivot
@adapttable/core/stream
@adapttable/core/sparkline

Those are outside the main core entry, so the application pays the bundle-size cost for those features only when it imports and uses them.

The adapters have feature-specific entry points too. Mantine, for example, exposes paths such as:

@adapttable/mantine/row-reorder
@adapttable/mantine/grouping
@adapttable/mantine/editing
@adapttable/mantine/virtualize
@adapttable/mantine/cell-navigation

v2 still keeps some optional feature implementations reachable from the main DataTable import graph, so the adapter side doesn't get the full bundle-size benefit from those entry points yet.

v3 will move those optional implementations out of the root import graph so applications only pay for the features they actually import and use.

The deprecated v2 APIs will be removed at the same time.

The server side changed a lot too

The original TableSource idea is still there: the table can work with local data or with data controlled by a backend.

That area has expanded quite a bit.

There is now a separate @adapttable/server package for parsing and validating AdaptTable query state on the server.

Pagination, sorting, filters, filter trees, grouping, and pivot state can use the same table query model on both sides instead of needing a second representation just for the backend.

Real-time updates are in now too.

AdaptTable can consume row patches coming through WebSocket or SSE flows instead of reloading the entire dataset whenever something changes.

The live-update work also connects with editing. A remote update can arrive while somebody is changing the same row locally, so those two parts of the table need to understand each other.

There is support for SSR, React Server Components, and streaming as well.

A lot of the work after v1 ended up happening around the data flow and lifecycle of the table, not only in the rendered grid.

Eight adapters, one engine

The public adapters today are:

Mantine
MUI
Chakra UI
Ant Design
Radix Themes
Base UI
shadcn/ui
unstyled/Tailwind

They all use the same underlying table state and feature logic while rendering with the components and conventions of their own UI stack.

A Mantine project gets Mantine components. An MUI project gets MUI components. A project with its own design system can use the unstyled path.

The core behavior stays shared across them.

Everything is still MIT licensed.

v3 is next

While working on v2, I kept running into one thing I want to fix properly in v3: too much of the engine is still tied to React.

A lot of what AdaptTable does has nothing inherently React-specific about it.

Sorting, filtering, grouping, pivots, formulas, query state, editing state, row models, and feature logic can all exist without React.

For v3 I'm moving that logic into framework-neutral engine modules, with React hooks and components living in a separate binding layer.

React will remain fully supported, but it won't define the architecture of the engine underneath it.

That also opens the door to Vue and Angular integrations later without rebuilding the same table logic for each framework.

v3 will also remove the deprecated v2 APIs and continue the bundle cleanup by moving optional feature implementations out of the root import graph.

I'm also working on optional AI capabilities for v3.

I Stopped Treating Long AI Coding Runs Like Chats — Nightshift Now Treats Them Like Shifts

Orwa Mahmoud — Wed, 02 Sep 2026 16:28:10 +0000

A while ago I wrote about a problem I kept hitting with Claude Code: I could give it a large task, walk away, and come back later to find that it had stopped somewhere in the middle.

That problem is what originally pushed me to build Nightshift.

At first, the goal was mostly:

How do I keep the agent working?

Once I got the agent to reliably work for hours, my focus shifted.

The problem was no longer just keeping it alive. I started focusing on improving the shift itself:

If I leave a coding agent working for several hours, how do I make that run something I can actually understand, trust, review, recover, and keep as history afterward?

That changed how I think about long-running agent work.

I don't really want a six-hour conversation.

I want a shift.

The shift should exist outside the chat

The core idea in Nightshift is:

The work contract and run state live on disk, not only in the conversation.

During a shift, I want to be able to open the files and see:

what is done
what is being worked on now
what is still open
what is parked or blocked
what decisions were made
what was tried and rejected
what still needs verification

The conversation is still useful for instructions, reasoning, and following the work as it happens. But for a multi-hour shift, I don’t want it to be the only place that remembers what was agreed, what changed, what failed, and what is still left.

That becomes especially important when context gets compacted, a session fails, or I come back the next morning and need to understand what happened without scrolling through one giant chat.

Two kinds of shifts

Nightshift currently supports two main ways of working.

1. Planned shifts

You define the work up front as a concrete feature plan.

For example:

[ ] build the Products module
[ ] add product categories
[ ] add coupons and discount rules
[ ] add inventory tracking
[ ] add product search and filters
[ ] audit the whole module end-to-end and make sure every backend flow has the required UI and works correctly
[ ] add tests and verification

Each item can have its own quality or verification requirements, and/Or you can also define checks that apply to the whole shift.

The shift keeps working until every contracted item is ticked off. Owner-defined quality checks describe what “done” should mean, but the model decides when an item is ready to tick. Nightshift tracks that state and mechanically prevents the model from clocking out while anything is still open. Whether the work is actually good enough is still for the human reviewer to decide.

2. Open-ended shifts

This mode became one of my favorite parts of Nightshift.

Instead of giving it a fixed checklist, I give it:

a goal + a strict time budget

For example:

Improve this product for the next four hours.

The agent can inspect the product, codebase, history, tests, existing issues, comparable approaches, technical debt, UX problems, or other useful opportunities.

It finds useful work, ranks it, works on the strongest opportunities, and then keeps going.

If it finishes one thing early and tries to stop while meaningful time is still left, the shift pushes it to continue exploring and improving until the time budget is actually over.

The stopping condition becomes less:

"The model feels finished."

and more:

"The shift is over."

A side effect I ended up liking a lot

This created a use case I didn't originally build Nightshift for.

Sometimes my Claude, Codex, or Cursor usage is going to reset the next day, and I still have a chunk of allowance left.

Maybe I don't have a feature prepared.

Maybe nothing is currently planned on the timeline.

Maybe I just have a few hours of usage that are going to disappear anyway.

Instead of wasting that capacity, I can start an open-ended shift and say:

You have three hours. Find useful work and improve the project.

Nightshift keeps the model working within that time budget instead of letting it finish one small task and stop after 20 minutes.

So the ready-made and open-ended shifts also give me a way to spend otherwise-expiring usage usefully when I don't already have anything planned.

Ready-made shifts

You don't always need to design the shift yourself.

Nightshift also has a catalog of reusable shifts for things like:

defect hunting
test coverage
quality debt
dependency upgrades
codebase review
Product Evolution

For example, Product Evolution is an open-ended shift that studies the product, its history, user needs, and relevant standards, ranks opportunities by evidence, value, effort, reversibility, and risk, then works on the strongest ones within the available time.

The catalog is useful when I know I want to spend a few hours of agent time productively but don't have a detailed backlog ready.

Longer term, I want this catalog to grow beyond my own workflows.

If someone has a long-running workflow that consistently works well, it should be possible to turn that into a reusable shift that other people can install, customize, and contribute back.

And I don't think those shifts necessarily need to be coding-only.

Recurring workflows like SEO, research, audits, or other reviewable agent work can fit the same model too.

I didn't want to build another agent runtime

This became an important design decision as Nightshift grew.

I don't want Nightshift to replace Claude Code, Codex, or Cursor.

Those tools already have their own ecosystems, commands, skills, hooks, capabilities, and ways of working.

Nightshift is designed to augment those ecosystems, not sit in front of them as another agent platform.

There is no Nightshift cloud service or account.

You don't need another npm CLI or Homebrew-installed orchestration runtime that proxies the agent.

Claude Code should still feel like Claude Code.

Codex should still feel like Codex.

Cursor should still feel like Cursor.

Nightshift adds the shift contract, state, enforcement, recovery, review, and archive layer around them.

Long-running doesn't just mean "keep looping"

There are already good ideas for keeping agents working for a long time.

Ralph-style loops, for example, already established patterns around persistent plans, specs, repeated iterations, and state that survives outside a single chat.

So Nightshift isn't trying to claim that file-backed plans or long-running loops are new.

The part I'm interested in is the accountability around the run:

what exactly was contracted
what is still unfinished
what quality bar applies
what decisions were made
what got blocked
what failed
what was verified
whether the session died
how it recovered
what evidence exists afterward

Keeping an agent running for six hours is useful.

Being able to understand what actually happened during those six hours is much more useful.

Recovery should survive the agent itself

Another part I didn't want to trust only to prompting was recovery.

If the process doing the work is also the only thing responsible for noticing that it died, that isn't very helpful.

Nightshift therefore has an external watchman.

For example, if a Claude Code session hits a structured API failure such as:

API Error: 500

the watchman can keep attempting to recover the recorded conversation when the API becomes available again.

For Codex, the watchman can recover a session once it is proven dead, preferring the recorded session when its identity is resumable. If that isn't possible, the on-disk contract still provides the handoff for a fresh recovery.

Failures will happen.

The goal isn't to pretend they won't.

The goal is that a temporary API or session failure doesn't silently throw away the remaining hours of work.

The shift doesn't disappear when it ends

This is one of the parts I appreciate more the longer I use Nightshift.

When I want to file away finished work, Nightshift can archive the completed part of the shift.

Nightshift moves completed items, handled snags, and the rotated journal into a dated archive. Receipts are copied into the dated archive too, while the live copies stay in place.

The active contract and any still-open work stay intact instead of being filed away as if they were finished.

Over time, those dated archives become a much cleaner history of previous shifts.

The original conversation might be thousands of lines long, but the archive gives me a short, structured record of what was completed, what decisions were made, what went wrong, and what evidence was left behind.

So instead of reopening an old marathon chat and trying to reconstruct what happened, I can open the archive for that date and understand the shift much faster.

Even a shift I decide not to merge can leave useful history.

Maybe the implementation wasn't good enough, but the investigation found something important.

Maybe an approach failed, and I don't want the next agent rediscovering the same dead end.

Maybe a decision needs to be revisited later.

That history is worth keeping.

Read the receipts, not the promise

The direction I'm pushing Nightshift toward is pretty simple.

I don't want the final handoff to just be:

"Done! Everything looks good."

I want to be able to inspect the actual state, diff, commits, verification, decisions, failures, and receipts myself.

Long-running autonomy becomes easier to trust when you don't have to trust the agent's summary of its own work.

Read the receipts, not the promise.

Where Nightshift is now

Nightshift is open source under MIT and currently supports:

Claude Code
OpenAI Codex
Cursor

It runs locally and is designed to augment those tools rather than replace them.

The project is still evolving, especially around reusable shifts, stronger review workflows, and making the same model useful beyond coding.

But the basic idea has become pretty clear to me:

Give the agent a real shift instead of one enormous chat.

Define the work or the time budget.

Keep the state outside the conversation.

Keep it working while the shift is active.

Recover when things fail.

Keep the evidence.

Archive the result.

Then review what actually happened.

Nightshift

If you're already leaving coding agents working unattended for hours, I'd be especially interested in the workflows you've found that consistently work well.

Some of them might make good reusable Nightshift shifts.

Why Claude Code Stops Halfway Through Long Tasks—and the Harness I Built to Keep It Moving

Orwa Mahmoud — Tue, 28 Jul 2026 17:08:23 +0000

I kept giving Claude Code long task lists, stepping away, and coming back to find it had completed the easy parts and stopped before the difficult ones.

Sometimes it was worse.

Claude would work until 2 AM, ask one non-critical question, and then sit idle for six hours until I woke up at 8.

The question was usually reasonable, but it was not truly blocking. Claude could have chosen a safe default, continued working, and left the decision for me to review later.

That is a harness problem, not only a model problem. The layer around the agent loop decides what “done” means, when the run may stop, and what happens when human input is unavailable.

That problem led me to create Nightshift, an open-source reliability harness plugin for long unattended Claude Code sessions.

Update (v0.6, July 2026): the night the API died

Since publishing this, the other overnight killer got its fix. Claude had elevated errors across multiple models one evening — API Error: 500, 529 Overloaded — right as I was about to start an overnight run. That is the failure no prompt can fix: once a session dies on an API error, nothing inside it can restart it. And I was not going to sit up watching status.claude.com.

nightshift now ships a night watchman — a small process outside the session that wakes every 10 minutes and reads only the session's own signals: its transcript, its recorded process, Claude Code's session roster. A session that died — or one wedged with an API error as the transcript's last word — gets claude --resume fired into the same conversation, and the watchman keeps knocking until the API answers. Esc or Ctrl-C always wins: it revives the endings nobody chose, never the ones you did. In the morning the whole night is one thread — the error, the revival, the finished work — with a direct link back to it.

Full details: the nightshift site · GitHub repo

Keeping the task outside the conversation

Nightshift uses a persistent Markdown punch list as the source of truth.

# Nightshift Punch List

- [ ] Add rate limiting
- [ ] Add tests for failed login attempts
- [ ] Update the API documentation
- [ ] Run the full test suite

Claude works through the list one item at a time.

Because the work is stored in a file rather than only inside the current context window, the session can recover after context compaction, interruption, or restart.

Preventing quiet early exits

Nightshift includes a stop hook that checks the punch list whenever Claude tries to finish.

If unchecked items remain, the normal stop is blocked and Claude is instructed to continue.

The shift ends only when:

every item is completed
the deadline is reached
an optional stall limit is reached
or the owner explicitly stops it

If no stall limit is configured, stalled work stays held and visibly flagged rather than quietly clocking out.

This is stronger than simply prompting Claude to “continue until finished” because the completion condition is checked against persistent state.

Non-blocking questions should not stop the night

Most human-in-the-loop systems pause the agent whenever it has a question.

That makes sense for destructive or high-risk decisions. It does not make sense for every naming choice, implementation preference, or reversible decision.

During a Nightshift session, non-blocking questions are parked with the default Claude chose.

## Parking Lot

- Question: Should the endpoint return 200 or 201?
- Default used: 201, matching the existing creation endpoints.
- Review later: Confirm API consistency.

Claude continues working, and the developer reviews those decisions in the morning.

The goal is not to remove human oversight. It is to make some of that oversight asynchronous instead of forcing the whole session to wait.

Guardrails for unattended work

Long-running autonomy needs clear boundaries.

Nightshift can mechanically enforce restrictions such as:

blocking git push
denying dangerous commands
protecting selected directories
checking diffs for secret-like content
enforcing a specific Git identity
preventing non-blocking questions from pausing the shift

A prompt saying “do not push” is helpful.

A hook that rejects git push is stronger.

These guardrails are not a security sandbox, but they reduce the risk of relying only on the model to remember every instruction.

Verification before completion

A checked box is still a claim made by the agent.

Nightshift cannot guarantee that the implementation is correct or replace code review. What it can do is enforce a more disciplined workflow:

implement the change
run the relevant verification
inspect the result
commit the completed item
mark the checkbox complete

Verification can include commands such as:

npm test
npm run lint
npm run typecheck

Nightshift also encourages one commit per completed item, making the run easier to inspect or partially revert.

Resumability and receipts

Nightshift stores operational state inside .nightshift/, including punch lists, parked questions, logs, deadlines, stop signals, and completion snapshots.

This state can have its own local Git history, separate from the main project repository.

That gives the developer two different records:

project commits showing what changed
Nightshift receipts showing what happened during the run

If the session is interrupted, a new session can inspect the same state and continue from the remaining work.

What Nightshift does not solve

Nightshift does not eliminate hallucinations.

It does not guarantee that:

every completed item is actually correct
tests cover every requirement
every chosen default is good
every unsafe command will be detected
a poorly written task list will produce a good result

It adds persistence, constraints, verification habits, resumability, and visibility around Claude Code.

Human review is still required.

Installation

Inside Claude Code:

/plugin marketplace add orwa-mahmoud/nightshift
/plugin install nightshift

Then initialize it inside your project:

/nightshift:setup

Review the generated punch list and start the shift:

/nightshift:start

Overview and FAQ:

Nightshift — Accountable coding shifts: long runs, recovery

Give Claude Code, Codex, or Cursor a durable punch list, safety rules, recovery, and a reviewable morning handoff.

nightshift.orwamahmoud.com

Nightshift is free, open source, and MIT licensed.

Contributions, issues, and feedback are welcome:

https://github.com/orwa-mahmoud/nightshift

One headless table engine, every React UI kit

Orwa Mahmoud — Sat, 04 Jul 2026 08:06:43 +0000

Every React project reaches for a data table eventually, and the choice always feels like a trap:

Reach for ag-Grid or MUI X DataGrid and you get power — but their look, their DOM, and (for the good features) their license.
Reach for TanStack Table and you get total freedom — but now you build every cell, header, filter, and pagination control from scratch.
Reach for a kit-specific table (Mantine, Chakra, Ant) and you're locked to that one kit, re-learning a new API each time.

I wanted one table that renders natively in whatever UI kit a project already uses, with the same features everywhere, and a headless escape hatch when the defaults aren't enough. So I built AdaptTable.

One API, real native components

The whole table is five lines:

import { DataTable, useFrontendData, type ColumnDef } from "@adapttable/mantine";

const columns: ColumnDef<Person>[] = [
  { key: "name", header: "Name", accessor: (r) => r.name, sortable: true },
  { key: "email", header: "Email", accessor: (r) => r.email },
];

function People({ rows }: { rows: Person[] }) {
  const source = useFrontendData({ data: rows, columns });
  return <DataTable source={source} columns={columns} rowKey={(r) => r.id} />;
}

Swap the import for @adapttable/mui, @adapttable/chakra, @adapttable/antd, @adapttable/radix, @adapttable/shadcn, or @adapttable/unstyled — same props, different kit.

The key part: it is not a wrapper that looks the same everywhere. Each adapter renders that kit's actual components — MUI gets Material elevation, Ant gets Ant's compact density, Chakra gets Chakra's tokens. Same behavior, native skin. Flip the switcher in the live demo and watch one dataset re-render through each kit: https://orwa-mahmoud.github.io/adapttable/demo/

Filters and state that live in the URL

My favorite part: open the filter drawer, set a status and a date range, copy the link — whoever opens it sees the exact same view. Search, filters, sort, and page all serialize into query params (q, page, f_status, …), so every view is refresh-safe, back/forward-safe, and shareable. No useState juggling, no wiring: declare the filters and the URL sync comes with them, identically for client-side data and server-side fetching (there's a router adapter for Next.js and react-router).

What you get for free

Sorting, filtering (with removable chips), global search
Row selection + bulk actions
Column management — show/hide, reorder, pin (sticky), resize
Pagination — numbered or infinite scroll, auto by device
Shareable URL state + saved views
First-class RTL / Arabic and dark mode
Optional virtualization — a 10k-row list mounts ~24 DOM rows
Client-side data and server-side (you supply the fetch) through one contract

Headless when you need it

Under every adapter is @adapttable/core — a headless engine with prop-getters (getTableProps, getRowProps, …). If the batteries-included adapter isn't enough, drop down and render your own markup on the same engine. You never hit a wall.

What it's not

No pivoting, grouping, or Excel-style editing yet— this is for the CRUD tables most apps ship, not analytics grids. If you need those, ag-Grid is the right tool.

Try it

Try it in your browser (no install): https://stackblitz.com/github/orwa-mahmoud/adapttable/tree/main/starters/mantine
Live demo (flip the kit switcher): https://orwa-mahmoud.github.io/adapttable/demo/
Docs: https://orwa-mahmoud.github.io/adapttable/getting-started/
npx @adapttable/cli init
MIT, stable v1 (1.1 just brought every adapter to full feature parity): https://github.com/orwa-mahmoud/adapttable

Feedback very welcome — especially whether the per-kit rendering holds up in your stack, and how the declarative API feels next to what you use today.