Conversation
| ) | ||
| return AsyncAgent(self._client, agent_view.id) | ||
|
|
||
| def from_id(self, agent_id: str) -> AsyncAgent: |
There was a problem hiding this comment.
This is probably a missing thing in API but I think we probably want name in here as well?
There was a problem hiding this comment.
Not sure what is missing in the API?
In any case, a synchronous (and fully client-side) from_id() like this fits with BlueprintOps.from_id() and such, so this seems reasonable to pair with the AsyncAgent.get_info() call.
jrvb-rl
left a comment
There was a problem hiding this comment.
This seems fine as a start. Might be good to add some TODOs to decide about local caching.
| ) | ||
| return AsyncAgent(self._client, agent_view.id) | ||
|
|
||
| def from_id(self, agent_id: str) -> AsyncAgent: |
There was a problem hiding this comment.
Not sure what is missing in the API?
In any case, a synchronous (and fully client-side) from_id() like this fits with BlueprintOps.from_id() and such, so this seems reasonable to pair with the AsyncAgent.get_info() call.
| page = await self._client.agents.list( | ||
| **params, | ||
| ) |
There was a problem hiding this comment.
Question: does the list() call return just the IDs, or the ID + additional info?
| return await self._client.agents.retrieve( | ||
| self._id, | ||
| **options, | ||
| ) |
There was a problem hiding this comment.
I'm wondering if we should cache the json response, so subsequent calls can return immediately? Also, if the list() call returns details instead of just IDs, we would want to return the deets we already have here.
One question on all of this, though: are agent objects on the server mutable? If so, then sticking with the "re-fetch every call" strategy may be better for now, since that way we don't need to worry about the local and server versions going out of sync. (Well, the user would need to worry about this in their code, but we would make no promises about it at this level...)
No description provided.