Skip to content
flowlakes FlowLakes documentation home

Record sessions

A record session is the AI that works a record with you. On a table where sessions are switched on, every record has one. It does not run on its own schedule: it wakes when something worth a run arrives, reads the record, its history and what it already established, and then either does what the record needs, asks you a question it cannot answer itself, or proposes a change for a person to approve. What it learned stays on the record between runs, so a session picks up where it left off rather than starting over. You do not build or configure an agent for this. The platform’s own resolver takes any record no specialist claims.

When you’d use it

  • Let the platform work a request from the moment it lands: read what is needed, check the current state in the connected systems, and propose the change.
  • Answer a question the session asked and have it carry on from your answer.
  • Take a record over yourself when you want to handle it, and hand it back when you are done.
  • See at a glance what the session currently thinks, what stopped it, and who is handling the record.

What you manage

Switching sessions on. On the table’s settings (Admin, Tables, the table’s Session section) you enable sessions and, if a record landing alone should start a run, set Wake on create in the table’s note. Without it, a new record starts a run only when someone addresses the session on it (an @mention in a comment) or when a fact arrives that the session did not have, such as one of its plans being executed.

Answering. When the session asks a question, the now card under the record’s title states the question and offers Answer as its one primary action. The question itself is a card at the end of the thread, the page’s single feed of comments, runs, plans and approvals, directly above the composer. Answer scrolls to that card and puts the cursor in the composer, with the question named above the box. Your answer wakes the session. When the question offers ready answers (a set of choices, or Yes and No), clicking one sends it as your reply at once; an option such as Other opens the box for your own words instead. An answered question leaves the card; your answer stays in the thread. If the session could not be woken, for example because it is on hold, the card says so.

Answering a question that names a person. When the question is about who, such as a leaver or a new owner, the question card offers Choose person instead of a text box. Pick someone from your tenant; typing a name in is not accepted, since the session can only act on a person it can look up. Your reply still shows the name you chose, so it reads like an answer, not a lookup.

Following up on what it posted. If the session left a finding or an answered question as its last word on the record, you do not need to ask it anything to bring it back. A comment from you, as the record’s requester or the person it is assigned to, wakes the session again to read what you said. A comment from anyone else is kept on the record, but it does not wake the session by itself; address it directly with the composer’s To control (set it to the agent, or type @agent), or mention it by name in the text. There is one composer on the page, under the newest entry of the thread, and the To control is the only switch on it: the caller, the team only, or the agent.

Taking a record over. Who is working a record is on the now card, and so are the controls. While someone holds the record, the card’s sentence names them and, if you may hand it back (you hold it, the record is assigned to you, or you can edit the record), its button reads Hand back to the assistant. The same control, and Pause the assistant, I’ll handle it while the session is open, is in the card’s More actions menu, so it is reachable even when the card is showing a plan or another fact first. The record’s full audit account, opened from the rail’s Audit link, keeps its own copy of the control. Taking over stops the session’s current run at its next turn, keeps everything it recorded, and pauses it: no run starts on this record, from any trigger, until it is handed back. The same control reads Hand back while you hold it; handing back reopens the session, and anything that arrived while you held it (a comment, an executed plan) wakes it once.

The Audit link, and the account behind it, only show for a viewer with the platform.agents.read capability (see the rail’s Audit link, below). A record another person holds cannot be taken from them; they hand it back first.

Stopping one run. The Stop action on a live run in the thread stops further calls after the current call finishes without pausing the session; the next fact wakes it again. Use Pause the assistant, I’ll handle it, from the now card’s More actions menu, when you want the session to stay out of the record.

The thread

There is no tab bar and no separate panel beside the record for what a session is doing: the thread is the page. It opens on its newest entries with the composer under them, scrolls on its own while the header, the now card and the rail stay still, and offers Jump to newest when something lands while you are reading history. Clicking into the composer opens the thread at full height: the header and the now card step aside while the navigation and the rail stay, and Escape or the corner control brings them back. The composer never takes more than a part of the column, so the thread keeps the rest. A History card in the rail lists how the record moved (opened, assigned, the response target, each plan once, at its latest state) and each line scrolls the thread to its entry. Comments, the agent’s plan cards, approval cards, sub-task checklists and the record’s own field-change lines all render in the one feed, oldest first, in the order they happened, with the composer under the newest entry. The agent speaks in its own words: its conclusion is the entry, with the agent as its author, and the steps it took fold under Show work. A long conclusion opens folded to its first lines with Read all; nothing is shortened, and it stays open once opened.

  • A plan card carries the agent’s proposed steps, one plain line each (“Set Priority to High”, “Run the workflow VPN health check”), each step’s risk as three bars with its word (Low, Medium, High) and whether it can be reversed (“Can be reversed”, “Cannot be taken back”, “Depends on the workflow”). Approve and run, Edit and Reject sit on the card itself. Edit takes a step out of the plan and records why; Reject asks for the reason the agent is given, and the box is required, never left to post a silent rejection. Once the plan runs, every step shows what happened to it, read back: “Done, landed as planned”, or the difference by name. The engine’s own account of the plan (the trust record, the masked names, the run’s tokens) is in the Audit, one link at the foot of the card for readers who may see it. A plan nobody clicked on reads Withdrawn instead of Rejected when the record it targeted closed, was deleted, or the proposal aged out: the card still says why (“the incident was resolved by Jane Doe”), because the system’s own decisions are audited and explained the same way a person’s are, never a bare status with no reason. A plan approved but never run (a worker with no way to act on it) reads Refused with the reason the engine gave, and offers Try again so the same decision does not have to be made twice once the cause is fixed.
  • An open question shows as a card at the end of the thread, directly above the composer; the now card’s Answer action scrolls there and focuses the box. When several requester questions were drafted together, sending any one of them sends the whole batch as one message, not one send per question.
  • A working run shows its steps live; a finished run folds its steps under its conclusion (“Show work, N steps”). The conclusion itself never folds. A failed run says one sentence per cause, with Technical detail for admins, and Try again only when trying again could plausibly succeed.
  • Records the agent actually read show as links, in its text and in a “Read” list under its conclusion.
  • Field changes from one rule or workflow collapse into one grey line naming every change; the line expands to the rows.
  • Sub-tasks show as a checklist card; All sub-tasks opens the full related list.

The classic view. For one release after this page shipped, the record’s menu (the three dots on the now card) offers Switch to the classic view: the task page as it was before, with the Activity tab on the left, the state steps under the title and the plan panel in the rail. The switch is one click, asks nothing, and holds only for this visit: every record page opens on the new view. Everything the classic view showed is also on the new page: all fields under More fields, related records under Related, every step under Audit. The classic page switches back from its header.

If a person is assigned to the record, or is currently holding its session, the now card’s sentence says so and names them (taking a record over always holds it; see above). The full account behind this, including run counts and token counts, is one click away on the rail’s Audit link. The Audit opens as a list of everything that happened on the record, newest first (when, who, what; a field change reads “Priority: Medium to High”; team-only rows are marked), with Download CSV and As JSON. The session’s own account of the record, its five questions, sits under a fold at the bottom with its own text and JSON download.

Task records have no tab bar: More fields, Related and Versions are links above the thread that open a side panel, and Session is one of those panels too, under a different name. The rail’s Audit link opens the record’s whole readable session account in a side panel. A relationship read failure on Related is shown with Retry instead of being presented as an empty list.

Audit is the admin and auditor view. The link only appears for a viewer who holds the platform.agents.read capability, the same one that gates the Agent Control Tower admin pages; everyone else sees the record’s thread and rail with nothing missing, since what a session is doing now is already in the thread. A desk agent who tries the read directly gets a plain refusal, never an empty panel.

Audit opens with what the session believes and is working on right now (the agent’s own notepad: what it has found, what it needs, what it proposes, what it has done, and the take-over control), then the runs on the record, then the readout. It shows live runs with the same identities as the thread, the last completed activity, turns and token counts. It updates while you keep the panel open. A running run can have no final privacy ledger yet; shielding takes place before calls, and its ledger is recorded when the run ends.

Each run lists its steps. A step the platform refused before doing anything, such as a filter naming a field the table does not have, is shown in amber with the reason and the words “nothing was read”. It is not a failure: the agent was told what was wrong, and the next step shows what it did about it. A red step is a real failure, with its code so you can report it.

The readout sections are in the order you decide in: what done means and whether it has been verified, what was asked and proposed, what the session was shown, what governs it, what left the platform masked, what it spent and what it cost. What left the platform masked is one line, a single count (“12 names and values masked before the model saw them”, counting each mask, not distinct people); the per-run breakdown behind it (which detector caught what, where a resolved value went, how many refusals) stays on the admin run surface, not here. Run lists and closed pursuit history each show at most ten entries, newest first. Live questions stay separate from closed pursuits.

From the record to the setup. The agent is set up for every record of a table, never on one record, so the record page does not configure it. It links to where that happens instead. The agent’s name on a run in the thread, on a plan card’s byline and in the readout’s What governs it rows opens the agent’s own page; each connection row there opens that connection’s page, and each house rule the page where it is edited. The links show for readers with platform.agents.read, the capability those pages need; everyone else sees the names as plain text. Where this comes from reveals provenance. Instruction links open the specific rule or skill that supplied the fact.

Verification evidence recorded means the platform has recorded its current structural evidence check. Confirm that the read-back demonstrates the stated criterion. It is not independent proof that the whole ticket is resolved.

Fresh tenants mask identities and values by default. Installed tenants retain their previous setting until an administrator or the operator’s masking-on script changes it. Choose the model on Connections and edit standing instructions on House rules.

The table’s own Session tab is a different screen: its handbook. The rail’s Audit link above reads one record. The table’s Session tab, under Admin, Tables, on that table, reads the whole process: the same house rules a record’s session is told (the company wide note and every connection’s note, both read only there, with a link to where each is edited), where each setting came from and what a process page may not lower, what the platform has learned for this table (an active line you can strike, a proposed line you can accept or dismiss, and any retired line with its reason), the closed cases marked canonical for this process (each with Endorse and Retire), the business rules, workflows and approval policies this table’s records run under, and, where recorded, tokens spent per verified outcome. A section this tenant does not have yet, or that you do not have permission to see, names why rather than showing an empty list.

What the platform learns

A learned line does not start switched on. When the same kind of change has been carried out and confirmed on a process a number of times, the platform proposes it as a line on that process’s Session tab, together with the sentence it would put on the shelf. You can accept a proposed line early, or dismiss it. Left alone, the platform switches it on by itself once the count rises further with no failure of that kind landing in between.

The platform proposes a line after 3 confirmed outcomes and switches it on after 5. A company sets its own counts on the company wide House rules page, and a process may raise either one, never set it below the company’s, on that process’s own Session tab.

Only outcomes that a person approved and that the platform later read back as confirmed count toward a line. A finding, a resolution note, an attachment, or wording the assistant produced on its own never counts, no matter how many times it repeats.

A change of the same kind that later fails withdraws the line, and so does a person’s Strike on an active one. A withdrawn or struck line stays on the page with its reason, never removed outright.

A learned line only tells the session what to do. It never gives it a tool, a connection or a permission it did not already have.

Reading the health of it

AI → Learned carries a compact card, Service operations health, over the last 30 days. It answers one question in several parts: how much of the work the platform carried, and how much of it finished without anyone having to sign off.

  • Work a session picked up is the share of records raised in the window that a session took on at all.
  • Closed and verified counts closed records with a recorded verification stamp. That stamp currently requires a stated criterion, a verified action and later external evidence. It does not establish that the evidence demonstrates the criterion. Review the read-back against the requested outcome before treating this metric as proof of resolution.
  • Closed with no approval is the number the whole programme is about. It counts records that closed with a verified outcome and with no person having approved any plan on them. On a new tenant it starts near zero and climbs as autonomy is earned on specific operations and as repeated work becomes rules.
  • The rest are the counterweights, so the number above cannot be read on its own: reopened records, changes whose read-back said the effect was not there, how long approvals waited, how many closed past their SLA, and model spend per verified outcome.

Why some rows say “not measured”. A row shows a reason instead of a value when the platform genuinely cannot answer it. Sometimes nothing has happened yet: with no records closed in the window there is no share to report, and showing a clean zero would read as “nothing closed well” rather than “nothing closed”. Sometimes nothing in the platform records the fact at all: human handling minutes has no owner, because no field holds time worked on a record, and same issue again has no owner, because nothing declares when two records are the same problem recurring. In both cases the row names what is missing rather than showing a number that would be a guess.

The same reading is available to an administrator at GET /admin/service-ops/health?days=30.

Good to know

  • Corrections stay available. Public comments are read in full alongside recent lifecycle events, within a protected-input limit. Current source receipts, pending actions and blocking questions take priority over optional case history. If required context cannot be loaded or fit, the run stops explicitly.
  • Older observations can be reopened. Sessions with the compute tool can select exact fields or rows from supported earlier results on the same record. Current permissions and privacy settings apply again. Older read previews can be shortened during a long run while their sources remain accessible.
  • Context limits and spend are different. The harness reserves room for output and records estimated context size separately from total token usage. Administrators can configure the selected model’s context capacity; an unconfigured model uses a reported harness fallback. These controls do not themselves prove that a finding is correct.
  • Check who the request concerns. Requested for and Requested by identify the people stored on the record. If the description names someone else, the session is instructed to ask which person is intended before drawing a person-specific conclusion or proposing a change. Supported directory observations retain the queried person’s identity and a reference to the actual run result. Older observations without that link remain unconfirmed as to who they concern. Source attribution does not itself verify a conclusion.
  • A wake must be earned. A record landing is not on its own worth a run. Address the session, set Wake on create on the table, or wait for a fact the session did not have.
  • Turning off the wake on create. Open the Assistant on the Agent page and remove “when a record is created” from the table’s moments. A fresh install leaves it off. A tenant that used the earlier Entra request mapping may have it on for requests, and this is where it is turned off.
  • Marking a test record. Start the short description with [TEST (any case, for example “[TEST] VPN drops every hour”). Incident Management’s Closure Reviewer does not run when such an incident is resolved. Everything else about the record is unchanged, and the word “test” anywhere else in a description is never a reason to change its resolution code.
  • Answers use the record page’s words. The session is shown each field’s label and each choice’s label beside the stored values, and an answer that names a field the way the database stores it (resolution_code=cancelled) is sent back to be rewritten. If it is still written that way when no retry is left, the platform posts it with the labels in place (Resolution code: Cancelled), never the raw names.
  • A plan waiting for approval says what it asks. The record’s timeline names the request and who can approve it, not only “Waiting for approval”.
  • What it already knows when it starts. Lines learned for this process load before a general one, and a line learned for a different process is never read here. The session also sees a short list of other open records that share this one’s service or configuration item, raised in the last 7 days: up to 5, with the total told when there are more. A process can choose its own relation fields instead of the platform default, on that process’s own Session tab.
  • A file you attach is seen. When the request’s own requester or assignee attaches a file while the session is waiting on a person, the session wakes and its instruction names the file. It never assumes what the file says: it reads the file only when it asks to, through the same reader every attachment goes through. A file from anyone else, or one attached while the session is not waiting, is kept on the record but does not wake anything.
  • Facts still land while you hold a record. Comments, executed plans and walls are recorded on the session’s notes while it is paused; nothing is lost, and nothing acts on them until you hand back.
  • Handing back pays one wake. However many facts arrived while you held the record, the session wakes once and reads them all.
  • A record that reaches its end closes the session, whether it was open or held. Reopening the record starts a fresh session the next time something wakes it.
  • Moving a record to a specialist is refused while a person holds it. Hand it back first.
  • Every change outside FlowLakes is a plan a person approves. The session never opens a connection on its own; see Plans and governance.
  • A worker that dies mid-run does not strand the record. The platform lands such a run as stopped within a few minutes and the session wakes again on the next fact.

How a session proves an outcome

A session can tell you it is finished in four ways, and only one of them means the matter is settled: resolved and verified. That word is not something the session gets to assert.

It writes down what done looks like, once. The first run on a record states the success criterion in a sentence: the state of the world that would mean the work is over, such as “this person is back in the finance group and their own memberships show it”. It is fixed from then on. A later run cannot move the target it is measured against.

Three separate facts have to line up. A call that returned 200 is the tool’s word. A change the platform re-read afterwards is the read-back’s word, and it lands on the session’s notes as a verified action. Neither is the outcome. The third fact is an independent check: something outside FlowLakes, asked again after the change, a different way from the one the change itself confirmed. The platform files that check itself: when a session reads an outside system after a change landed, the read is written onto its notes from the run’s own record of what it did, with the tool, the operation and the time, whether or not the session thought to mention it. Only with all three does the session get to say resolved and verified, and the platform, not the session, stamps when that happened. The stamp does not wait for the session’s word: the moment the three facts are on the notes it lands, even when the run that took the read went on to propose the plan that closes the record.

A person saying “yes, that works” is recorded, and it is not the third fact. Your acceptance and a technical check are different things and the record keeps them apart.

If any of the three is missing, the session says so plainly instead: the change is waiting for approval, a person owes it an answer, or it looked and changed nothing. An honest dead end reads better than a decorated one, and a queue you can filter on the difference is worth more than a paragraph.

How it connects

The session is not a specialist agent: specialists still exist and a table can name one for records of a certain shape. What the session may reach comes from the tenant’s connections (External capabilities); who approves what it proposes is the approval ladder (Plans and governance); what it may read is the table’s session settings (Safety model).

Now do it: switch sessions on for a table and set Wake on create in its note.

Exact shapes: the record’s session state is served at GET /tables/{table}/records/{id}/agent-cases; take-over and hand-back are POST .../agent-cases/{case_id}/take-over and .../release.