Agent activity and versions
Where to look at what an agent has done, who sees what, and how the version history of its settings works.
An agent carries its own history on two levels: what it has done and what job description it had at the time. The two are more connected than they look – so we start with the settings.
A colleague's remit changes over time, but what they delivered last year, they delivered under the rules of the day. For an agent that holds literally: whatever happened once stays tied to the settings that applied then.
Every save is a version
What forms a version
Agent settings are not saved by overwriting. Every save creates a new version, and the previous one stays as it was.
| Part of the version | Outside the version |
|---|---|
| Instructions | Name |
| Files | Description |
| Knowledge | Spending limit |
| Tasks | Other people's access to the agent |
Changing several of them at once creates one version, not four. In the panel you recognise them by the fact that this foursome sits together in the Agent settings block.
What it is for
So that finished work stays readable. A historical chat renders with the instructions, model and data that applied then, not with today's. In the run detail you see it as the Settings version field.
When settings change mid-run
If someone saves a change while the agent is answering you, the answer in progress finishes on its own version. The new one is used from the next message in the same chat.
Version history
Where it is
The icon in the header of the Agent settings block. It lists versions newest first, each with a date, time and author; the one in force carries the Live badge. Selecting one shows its full content on the left, read-only.
Going back to an older state
The Restore button. It overwrites nothing and does not turn back time – it creates a new, newest version with the content of the selected one. History therefore only grows and finished runs stay on their versions.
| Situation | What happens |
|---|---|
| The version contains a dataset deleted in the meantime | The restore is not performed and the agent stays where it was. |
| The version contains a dataset you do not manage | You cannot restore it – the same rule applies as for adding datasets. |
| Someone else saved in the meantime | Datify offers Save my changes or Load the newer version. It will not overwrite someone else's work. |
Agent activity
Three cards
| Card | What is on it |
|---|---|
| All | Everything together. |
| My chats | Your own conversations with the agent. |
| Tasks | Runs the agent started on its own schedule. |
What is on a row
The name, Started by (where the run came from), status, when it was created, the model and the AI credits spent. Statuses: Running, Awaiting input, Completed, Failed, Stopped and Skipped – the last belongs to runs that did not start because the spending limit was exhausted.
The list can be filtered by status and origin, searched through Search activity and sorted newest or oldest first.
Who sees what
The rule is short: personal chats are private, automated runs are shared. What you discussed with a colleague one-to-one stays between you; what they delivered as their standing work is visible to the whole team.
Only you see them. Sharing the agent does not share them – neither other managers nor the workspace administrator will see them.
Everyone with access to the agent sees them, including their progress and result. They belong to the agent, not to an individual.
A less obvious thing follows from the first: you see your chats for as long as you have access to the agent. If someone takes it away, they disappear from your overview along with the agent – they are not deleted though, and once access is restored they reappear as they were.
Deleting a dataset does not erase history either. The text of old answers stays; only a link to a record that no longer exists may fail to open.