The assistant (Cobb)

Cobb is the chat assistant that lives inside a workspace. It answers questions, and when you ask it to, it acts on your workspace: create a record, update one, run an action, change how the workspace is set up. Cobb runs on the AI provider you connected. With none connected it drops to basic mode, which does far more than canned phrases.

The loop:

1. Open the panel, or press Ask Cobb on the screen you are on.
2. Press a record's Cobb button, or tick rows and press Ask Cobb in the bar that appears, then say what to do with "these".
3. Type. Confirm each proposed change, and Undo anything you regret.

What Cobb can do

Cobb uses the same tools the rest of the app exposes, under your own permissions: it cannot see or do anything you could not, and a member cannot reach admin-only settings through it. He answers plainly and never shows you the internal ids of your own things.

• Read your records. Search across kinds, list and read records, follow the links between them ("which projects use this part?"), and read your put-away plan. It looks at what is actually there rather than guessing.
• Read how your workspace is put together. The separate lists one module runs, your saved views and whether they are pinned, your automations (what each wire does, what sets it off, whether it is on), your apps, templates and units. Ask "how is my workspace set up?" for all of it, or about one part. That answers "why did that happen by itself?" and "why didn't it?", since a switched-off wire is named as such.
• Read what is happening, not just what you have:
  • What needs me. The same needs-you feed your dashboard shows: stock run low, dates overdue or due in the next 30 days, captures still waiting to be filed. It reads your own fields, so it covers trackers you built yourself.
  • What changed. The activity log: who created, edited or deleted what, and when. A change by a wire or an API token says so rather than looking like a person's.
  • What I missed. Your notifications in this workspace, unread ones marked.
  • What is due for service. Scheduled and completed maintenance across machines, vehicles, assets and tools.
  • What is coming up. The workspace calendar over any window. Ask "what's on this week?" without naming dates and it works the window out.
• Read your scan inbox, item by item. What is waiting, which need a look, what has sat longest, whether you scanned a particular thing. It narrows to the Scan page's four filter groups (needs review, waiting, unfiled, ready), and counts come from the whole queue, so "15 need a look" means fifteen.
• Answer questions about Cobblr itself, from the app's real features. Ask about a navigation heading and he names the screen that makes it, and he says he is not sure when something is not a feature at all.
• Propose a change. Create a record, update fields on one (including the custom fields you added, with their dropdown choices), delete one, tag or shelve one, or run a registered action on a record it found by name. Every action carries the phrasings someone would actually use, so "used one", "that order turned up" or "put the racks in order" reach the right thing rather than a guess from an internal name. The confirm card says what it will do ("Add a category: Kitchen & Grocery"), never an action's id.
• Make a whole set in one go. "Each rack should have Shelf 1 through 5" is one request that takes seconds, not sixty. It arrives as one line in the chat with a single Undo. Anything already there is counted rather than duplicated: "Added 58 locations. 2 were already there." Up to 200 records in one request.
• Build you a view. Ask for "a board of my open tasks" or "a calendar of what is due" and Cobb proposes saving it, pinned to your dashboard if you want. It knows a board is a kanban and a timeline a gantt, and says so plainly when this workspace does not track what you asked for, rather than saving a view that opens empty.
• Change how the workspace is set up. Fields, field sets, form layout, what a list is called, features, the workspace name, your navigation: all by asking, and he runs the change rather than pointing you at the screen.
• Design a whole workspace from a description, which hands off to the AI builder.

What Cobb won't do

He knows which fields of a record he is not allowed to read, and says so. Asked about a field a module keeps private (a vendor's notes, a machine's serial), he answers that he cannot see it from here and where it can be read, rather than "none".

Some decisions belong on their own screen, where you can see everything they touch: inviting or removing members, API tokens, backup and restore, AI provider settings, composing automations (switching one on or off is fine), and a field's type or the data stored behind it.

• He walks you there with the form filled in instead, and nothing is ever submitted on your behalf. Say "invite sam@example.com as an editor" and your screen moves to Members with the email and role entered and the Send button waiting for you. More on what stays on a screen.

Pointing Cobb at something

Tick rows and press Ask Cobb, press the Cobb button on a record, or open him from the screen you are on, and the question is about that. It has its own page.

Answers before you press enter

"How many Bambus?", "do I have any deltas?" and "which model do I have the most of?" are answered from your own records while you are still typing, counted in code with no AI used. The count looks at every field of every record, so a brand that only appears in a manufacturer field is found. Anything it cannot count exactly is left for the assistant.

As you type a question Cobb can answer without a model, the answer appears in a green bubble under the conversation, before you send anything. All three kinds work with no AI connected. Enter still gets the full answer from a model.

• From the page you are on. "What page am I on?", "where am I". The browser already knows, so nothing is asked of anyone.
• Straight from your workspace. "How many parts do I have?", "where is my drill", "what's low on stock?". One read of your records, no AI.
• From what Cobb already knows. "What can you do?", "how do I add a part", "where do I scan?". Built-in answers you can edit and add to under Configuration then Assistant.

Why it is deliberately narrow

Each bubble says where the answer came from. An answer shown unprompted must never be a guess, so a word that is not one of your record types, a noun matching two of them, or anything that would change something is left alone and goes to the assistant when you press enter.

Three controls at the top

Two consent controls decide what Cobb may do in this workspace, and a third picks which AI answers you. All three are per person, and the consent ones are enforced on the server rather than in the panel.

• Read my data. On by default. Cobb may read your records into its answers. Turn it off and Cobb answers from general knowledge only and will not claim to know what is in your workspace. Everything under "What Cobb can do" above obeys this one switch.
• Changes, a chip that cycles through three settings:
  • Changes: off removes change proposals entirely. Cobb answers and explains, but offers no creates, updates, or actions.
  • Changes: ask is the default. Every change is a proposal you confirm before it runs.
  • Changes: auto applies record creates and updates immediately, and lets Cobb chain them. Each one is tracked and can be undone.
• The model pill shows which AI is answering you. Click it to switch between the models the workspace has configured and any connection shared into it, each with a note on what it costs or how strong it is. It is your choice for your chat only, and the last row returns you to the workspace default. A model that stops being available falls back to the default rather than to nothing.

Where your records go when Read my data is on

When Cobb reads your records, the matching records go into the prompt to your workspace's AI provider. With a shared AI, that is another member's connection.

Which actions ask

On Changes: ask, every action Cobb proposes from the chat panel comes back with a confirm button. On auto, the actions that can be undone inside the workspace run at once with their own Undo: reordering, tagging, adjusting stock, moving records between lists, logging an entry, completing a task. A record delete, and any action with no way back (print a label, command a device, empty a list), still waits for your confirm even on auto, because the ledger has no inverse for an arbitrary side effect.

Asked to change something, Cobb makes the change rather than describing how it would be made, and looks a record up before answering a question about it, so "who makes this machine" is read off the record rather than recalled. When the workspace has already worked out what a request means, he runs exactly that plan and says what he did.

From a connected assistant rather than the panel, the rules are stricter, because that connection has no way to show you a confirmation dialog:

• Writes need Changes: auto. On Ask or Off, the connection is told plainly that changes are not allowed and what to switch to.
• An action runs only if its module declared it reversible. Anything else is refused by name, with the reason and the fix: run it from Cobblr, where the confirm step appears. The tool that lists actions marks which are which.
• Actions default to not reversible, so a newly written one is cautious until someone decides otherwise.

Undo puts it back

Every change records how the record looked before and after, and Undo restores that state rather than performing the opposite operation.

• A create is undone by removing the record.
• An update is put back in full, including fields the change touched indirectly, not only the ones it named.
• A delete brings back the same record with the same id, so children, labels and anything filed under it still point at it.
• A whole instruction is one thing to take back. When Cobb changes several things at once you get one card listing what he did and one Undo for all of it, and pressing it says what happened there rather than adding lines to the conversation.
• Every action that ran offers Undo, and Undo puts it back: a stock move restores the count and the lots, a tag comes off, a reorder goes back, a completed task reopens, a move between lists is the same move the other way. A run that changed nothing offers no Undo, and a card that cannot be undone from the chat says so instead of a bare "Done".
• An undo is itself a ledger entry, so you can undo an undo.
• It never takes back what you did. If you edited the same record after Cobb did, your edit stays. Only the parts still as Cobb left them go back, and the panel names what it kept ("Left the notes as you set it").
• An undo that stops short offers you the rest. "Put back 5 of 6. Left Shelf 3 alone, because you have changed it since" comes with a button. Taking the offer is itself a tracked change you can undo.

Why restore-a-state rather than do-the-opposite, and every refusal

Doing the opposite is a new forward write: it earns a new id, re-runs the rules meant for new records, and can produce something that merely resembles what was there. The ledger is what makes Auto safe to offer: nothing applies that you cannot walk back. Only where a kind has no restore route does a delete fall back to recreating a copy, and then it says so.

If you changed the very field Cobb changed, the undo declines and says why, because yours is the more recent word. Undoing a create will not delete a record you have since renamed or filed things into, and undoing an edit never brings back a record you have deleted. Each refusal says what to do instead, and nothing is ever silently reverted on your behalf.

Your conversation stays

• The chat is kept per workspace on your device, so a refresh or reopening the panel picks up where you left off. It is not uploaded. A trash icon in the panel header clears it.
• A question Cobb is still working on survives too. Each question runs on the server, so a reload or a second tab picks the same one up mid-way, and the answer arrives in whichever tab is watching. Before, a refresh threw the answer away.
• The up arrow brings back what you sent before, and the down arrow comes forward again, the way a terminal does. A half-typed message is kept while you look and comes back at the end, the history survives a refresh, and inside a message of several lines the arrows still move the cursor.

Watching him work

While Cobb works, the panel lists what he has done rather than the single word "Thinking".

• Each step appears as he takes it, in plain words about your workspace ("Reading your locations", "Searching for drill", "Running adjust stock"), ticks green when it finishes, and the one in progress carries a running clock once the wait is long enough to wonder about. A failed step is marked rather than dropped.
• A record he names is a chip you can open, in his read answers as well as in the cards for changes: ask which books you have and each one opens its own page, the words around it kept. He never links a name he did not just look up, a name two records share stays plain text, and a chip says so if the record has been deleted since.
• Answers arrive as they are written, a few words at a time, when the provider supports it and the turn is a plain answer rather than one calling tools (a half-arrived tool call is not something to show). A reply that takes ten seconds starts appearing after about three.
• His pose tells you what is happening. Cobb, the little cobbler on the AI surfaces, greets you, works at his bench while something runs, points at what he is proposing while it waits on your confirm, and holds up the result when a build lands.

Personal connections, and where Cobb stands on an empty panel

This holds however your AI is connected. When your assistant is a personal connection that runs the tools itself, each of its changes appears in that list as it happens, so a long request reads as visible work instead of a spinner.

On an empty panel Cobb is full size, and he steps aside as soon as there is something to show so his first answer arrives where every later one does.

When the provider has no tools

Some models do not support the tool-calling protocol Cobb prefers. Then Cobb falls back to a simpler one-move-at-a-time exchange: proposals and confirmation work the same, but it is less able to chain several reads and writes in one turn. Which providers support the full loop, and how to handle a local backend that runs its own tools, is on Choosing a provider.