I used to track my active customers in a project management tool. Updated it by hand — stage, priority, last interaction note. When I needed an AI to do something with it — draft outreach, flag follow-ups, summarize where things stood — I'd copy the relevant rows out of the tool, paste them into a chat, get back what I needed, and then manually update the tool with whatever changed.

This works, for a while. Then it starts feeling like you're doing the job of an API. The AI only knows what you pasted in. The tool only knows what you typed back. When the session closes, nothing carries over. Next time, you start from scratch. The customer data and the AI-readable context live in separate places, and you are the one shuttling between them.

That's the problem. Not the tool — tools are fine. The problem is static data plus manual context transfer. Every AI-assisted task starts with you doing a copy-paste that shouldn't exist.

A state object in Waxell Connect is a live, versioned, agent-readable data record — not a file a human opens, but a structured piece of data that agents can query, update, and act on across sessions, without anyone re-entering the context.

That's what state objects are. Here's what makes that different in practice.

Documents are passive. State objects are active.

When I moved my customer list into a state object, the first thing I noticed was that agents stopped waiting on me. Before: I updated the tool, I pasted context into a chat, the agent used it. After: the agent reads the state object directly when it enters the workspace. A customer completes onboarding — the state object updates. A follow-up task triggers automatically because the object changed. I don't paste anything.

This isn't a subtle distinction. A document — or a row in a project tool — is a record of what was true when someone last typed into it. A state object is what's true now. The gap between those two things is where most automation breaks down.

What a state object actually looks like

In Waxell Connect workspaces, a state object is a JSON-structured record attached to a workspace. It has fields. Those fields are typed — strings, numbers, booleans, dates, arrays. Agents reading into that workspace can call the state object, check specific fields, and make decisions from what they find.

My customer state objects have fields like: lifecycle_stage, onboarding_complete, last_contact_date, open_issues, tier. When an agent drafts a follow-up email, it doesn't ask me who this customer is. It reads the state object. The email already knows their tier, what's outstanding, and how long since the last contact.

The same pattern works for anything that changes over time. I have a content tracking state object in my blog workspace that stores the current cluster rotation, the last published date, and the keywords used. The scheduled task reads it before picking the next post topic. No one updates this manually. The task updates it when it's done.

Why not just use a database?

People ask this. The answer is that a database isn't part of the workspace. The point of a state object is that it lives inside the same context layer that agents already operate in — co-located with the playbook, the files, the channel history. When an agent enters a workspace, state is already there. No separate query, no separate authentication step, no separate tool call. The workspace is the unit of truth, and state is part of it.

For simple, high-read/high-write operational data, state objects are the right fit. For normalized relational data at scale, you'd use a real database. I use Connect for the former — customer stages, content queues, task tracking. Things agents touch frequently and humans touch occasionally.

When the agent maintains the record, you stop being the bottleneck

Before, every workflow that needed fresh context had a human in the middle — the person who opens the tool, copies the relevant rows, pastes them into a chat, waits for an output, and types the result back. That's four manual steps to get an AI to do one thing with information it should already have.

State objects remove that role. The agent does the work, updates the object, and the next agent in the chain reads from it without anyone between them.

My setup: I use Claude Cowork as the interface for working with Connect. When I open a session, the agent enters the relevant workspace and reads whatever state it needs before doing anything. I don't paste context in. I don't prep a brief. The state object is already there. That's not the only way to interact with Connect — you can use the API, the web UI, or whatever you've built — but for me, the Cowork + Connect combination is what makes the no-copy-paste thing actually true end to end.

For me the flow looks like: customer triggers a webhook → agent logs the interaction → state object updates → follow-up task is created automatically because the object changed. I see the follow-up task. I don't see the four steps that produced it.

Tables in Connect operate on the same principle for structured, multi-row data — sprint boards, content calendars, project trackers. State objects are the single-record version of that same idea: one workspace, one live record, always current.

What it isn't

Worth saying clearly: a state object is not a replacement for every kind of file. Long-form writing, reference documents, guidelines, uploaded assets — those stay as files. A state object is for structured data that changes and that agents act on. My brand voice guide is a file; my content queue is a state object. A customer's uploaded contract is a file; their lifecycle stage is a state object.

Getting that distinction right matters. I made the mistake early of trying to put too much into state objects — including things that agents needed to read but not update. Files are faster for read-only content. State objects earn their place when the data is live and the agent needs to write back to it.

Getting started

The right first state object is usually the simplest version of whatever you re-enter most often — or whatever you currently paste into a chat to give an AI context. For me it was the customer list. For others it's the project status, the content backlog, or the current sprint. Pick one piece of data, move it out of whatever tool you're shuttling it from, and put it in a workspace where your agents can reach it directly.

The setup takes time — maybe an afternoon to structure the fields correctly and test that agents are reading from it as expected. It's worth it. Once it runs, it runs without you.

Early access to Connect is open at waxell.ai/get-access if you want to build this.

Frequently Asked Questions

What is a state object in Waxell Connect?

A state object is a live, agent-readable data record stored inside a Connect workspace. Unlike a document or a row in a project management tool, which is static until someone edits it, a state object is a structured JSON record with typed fields that agents can read, update, and build decisions from across sessions — without a human manually entering or refreshing the data.

How is a state object different from a document or file?

A document is written once and read. It's static until someone edits it. A state object is designed to be written and read repeatedly by agents as well as humans. The key difference is ownership: documents have human authors who update them; state objects can have agents as primary maintainers, with field values changing as workflows progress.

What kinds of data should go in a state object?

Operational, high-change data that agents act on: lifecycle stages, queue positions, statuses, dates, counts, flags. Things that change frequently and that agents need to read and write without human intervention. Long-form content, reference materials, and uploaded files should stay as workspace files — not state objects.

Can an agent update a state object without human input?

Yes. That's the primary use case. A scheduled task can read a state object, complete work, and write a new value back to the object — updating the rotation position, the last-run timestamp, or a status flag — without any human in the loop. Other tasks that run afterward read the updated state and pick up from there.

Do I need to know how to code to use state objects?

No. Connect handles the read/write mechanics. You define the fields and what they mean; agents use them through the workspace layer. The closest thing to a technical requirement is thinking clearly about your data structure — which fields, what types, what the empty state looks like. That's architecture thinking, not programming.

How do state objects relate to Connect Tables?

State objects are single-record data structures — one object per workspace, with named fields. Tables are multi-row structures, like a spreadsheet or a project tracker, where each row is a separate item. Use state objects for workspace-level configuration and operational metadata; use tables for collections of things (articles, customers, tasks) where each row shares the same schema.

Sources

• JSON Schema Specification — for understanding typed field structures in structured data records: https://json-schema.org/specification

• Martin Fowler, Patterns of Enterprise Application Architecture (Addison-Wesley, 2002) — on persistent state as a foundational pattern in application design: https://martinfowler.com/books/eaa.html