Naming Things about agency

[operand]

hey @tensiondriven! Thank you so much for reaching out! This is great feedback. No criticism taken at all! I don't want rush forward with a flawed or confusing metaphor. And since using an actor model with agents is a new-ish idea, I expect iteration will be needed, so please don't hold back as you have ideas! I'm 100% here for it and unafraid of completely redoing things if necessary.

You brought up multiple points above. Let me break them out.

I'm not clear on what you're picturing for actions and messages and I'd like to better understand what you mean, or where there's confusion.

I use the terms to mostly mean the same thing. A "message" is basically carrying the "invocation of an action", asking the other agent to do it. It could be thought of as doing something to them. It's like a method on an object or similar to how http has verbs like "GET" and "POST".

Yeah I realize I did something confusing with the "say" action and I need to fix that. I think I get what you're saying.

I initially made the "say" action as a custom action on the chatting agents, intended as the action you'd call to send them a chat message, but then I ended up using that as though it was a special built-in method. I had a nagging feeling about that...

If you look at the base Agent class, the only special actions are supposed to be:

• help
• error
• return

But I ended up reusing the "say" action in the default implementations of return and error. I was taking a shortcut there and I kinda meant to circle back and didn't.

I'll probably step it back and instead of implementing defaults for return and error, I'll leave those unimplemented by default and expect that subclasses must implement them.

That would leave "say" as just being a custom action that is used on the chat agents only. I hope that makes it clearer on what was intended.

Regarding separating the space and agent name into separate fields.

This is a tough one and I'm still not sure of the schema so I'm glad you bring this up. I had thought of that too and decided to keep it as one for now, thinking that it is enough to address any agent in the system. I almost even combined the action name as well, but I felt that definitely warranted its own field.

I could be convinced to break out the space as a field, but I have some hesitation.

My concern is not whether we can easily build software that works with it. For that we can have a complicated schema all day.

My hesitation is because I want to try to keep the schema easily usable directly by human users and LLM agents as well, so I want to minimize how much is needed to understand or type out. One could look at the to field and not have to understand anything about the concept of spaces. The word "to" is pretty clear that it's the target or address that you're sending to or interacting with.

As an example, if you try the chat interface which implements a command syntax, in the current implementation you can type: /say to:So.And.So content:"hello there" in order to direct a message specifically. And this is just a small variation on the message schema itself.

Adding a space field would mean that users may have to break out to:So.And.So to to:So space:And.So. Of course we could just update the CLI parser to use the former syntax, but that's just extra work of another kind. And a similar argument goes for LLM agents. It's an additional thing they have to understand, or we'd have to translate in software. They currently don't need to be aware of the concept of a space at all and are able to address other agents correctly.

This is cutting to the core of the vision here, so it's a really good question and I'm not claiming I have it right yet, just explaining my thinking so far. It's not even a sure thing that we can find a single schema that will work well for all agent types. It's a bit of an assumption or ideal that I'm striving for. I believe that if we could identify a "lowest common denominator" for the message schema, it should make more things easier to integrate with. It's a challenge. But super interesting!

Maybe some testing is in order. If LLMs have an easier time with a different format, that would be enough to convince me to change it.

[operand]

just updating here to mention that I pushed an update to fix the "say" action behavior. Version 1.0.2 has it.

[operand]

gonna leave this up for a bit in case others have more thoughts or feelings on naming or general API "feel". I definitely want to hear more if it's confusing etc. Don't take my longform responses as defensiveness. Genuinely trying to make something that people find useful so please tell me what I need to hear :)