Set up the workspace base class

[collijk]

Background

Interface definition for the Agent workspace class.

I am thinking of the agent workspace as simply a path management tool, as that is how it is abstracted in the current system. We could also build some kind of WorkspaceResource abstraction that hides path management entirely from the Agent (which may be safer. This is also a pivot we can make later.

Changes

New base class for workspaces

Documentation

Typing and docstrings provided for all public methods.

Test Plan

Peer review

PR Quality Checklist

• [X] My pull request is atomic and focuses on a single change.
• [X] I have thoroughly tested my changes with multiple different prompts.
• [X] I have considered potential risks and mitigations for my changes.
• [X] I have documented my changes clearly and comprehensively.
• [X] I have not snuck in any "extra" small tweaks changes

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
docs	⬜️ Ignored (Inspect)			May 4, 2023 3:47pm

[Boostrix]

as mentioned elsewhere, given the ongoing work on supporting multiple agents/projects and tasks using potentially sub-folder, it will make sense to use the workspace as a "boundary" - especially in the context of sub-agents, it might get weird quickly if we don't formalize how exactly workspace access among agents and sub-agents works.

For instance: should sub-agents be able to access workspaces of other agents, or their parent workspace ?

Also, like you said, path validation should surely be a part of a "workspace" manager abstraction.

[anonhostpi]

I think generally, accessing parent "workspaces" is a bad practice. If we compare "workspaces" to node.js's modules, Node has deprecated module.parent for this reason. It doesn't make sense from a security perspective to give a child process management access to the parent. It doesn't follow "security through least privilege" at all.

A child process/workspace/module should be treated as that, a child process.

https://nodejs.org/api/modules.html#moduleparent

[Boostrix]

right, that was exactly my point - however, parent agents may still have a valid need to access child workspaces (workers). Some of us have started tinkering with multiple projects/agents and task hierarchies using sub-folders, i.e. sub-workspaces - and even the official repo seems to have work going in that direction. So it's definitely worth thinking about the implications for a "Workspace" base class

[pinuke]

I agree with that. In fact, that's exactly how node.js chose to fix the problems with module.parent.

They phased it out with module.children

[collijk]

I am non-commital about the relationship between the workspaces of multi-agent systems. There are for sure valid agent systems where there are reasonable parent/child relationships. There are also proposed systems with peer agents. And proposed systems with agents who obtain domain expertise and so the power dynamic is dependent on the task being worked on. I'm thinking of any agent workspaces as independent and their communication happening via message passing, as that allows for pretty much any agent network structure we like.

[collijk]

All such considerations are on the table, but out of scope for the work we're doing here. Just trying to get a binding between an agent and a workspace and get usage of that workspace consistent across the library.

[anonhostpi]

Still important to have the convo tho. Need to be prioritizing secure or proven practices whenever possible to prevent unpredictable or insecure behavior.

[Boostrix]

I have begun tinkering with different schemes to be able to "partially recover" a crashed agent's workspace to make heads and tails of leftover artefacts.

The thing is, finding a bunch of files and directories is one thing, but not that useful - we also need to know their purpose scope. Depending on the previous instance, it may have taken the agent to generate a ton of scripts inside the workspace using a "plan" - the new agent must know the purpose/state of such scripts to be able to reuse them, or to be able to continue working on them.

And I would like to discuss some sort of workspace manager abstraction - because for this stuff to work, we need to be able to different between different types of stateful actions. This could be encoded as part of the Command stuff (#3824) - so that we know what sort of "side effects" these commands have regarding the workspace in particular.

Using one method, I got this working pretty well actually - but it's still a hack, it would be much better and easier if actions/commands were to notify the workspace abstraction about side effects, so that a proper persistence scheme can be implemented on top of this

see: #4063