Add agent persona methods to the client - #24
Merged
Conversation
The agents service reads and seeds personas over Yeti's API, and had to build those URLs itself from `_url_root` -- a private attribute of this class, which nothing obliges it to keep. Personas are ordinary Yeti objects with an ordinary CRUD API, so they belong here alongside the other object types rather than being reconstructed by each caller. search takes no required arguments, unlike the other search methods: listing every persona is the common case, and Yeti's endpoint defaults to matching all. `enabled` distinguishes None (either) from False, which has to reach the API. No delete: do_request supports GET, POST and PATCH only.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds
search_agent_personas,get_agent_persona,new_agent_personaandpatch_agent_persona, covering Yeti's/api/v2/agentpersonasendpoints.Why
yeti-agents reads and seeds personas over this API. Without these it builds the URLs itself:
f"{client._url_root}/api/v2/agentpersonas/search"_url_rootis private, and nothing obliges this class to keep it. Every other Yeti call in yeti-agents already goes through a typed method here —semantic_searchwas added for exactly this reason. Personas are ordinary Yeti objects with an ordinary CRUD API, so they belong alongside the other object types rather than being reconstructed by each caller, along with the response envelope ({"personas": [...], "total": n}) that callers currently unpack by hand.Two deliberate departures from the neighbouring methods
No required arguments on search.
search_entitiesand friends raise if you pass nothing, because an unfiltered dump of entities is rarely what anyone meant. For personas the opposite is true — listing all of them is the common case, and Yeti'sPersonaSearchRequestalready defaultsnameto"", meaning match-all.enabledis three-valued.Nonemeans "either" and is omitted from the payload;Falsehas to be sent, since it is a real filter and not an absent one. Guarding withif enabled:would silently turn a search for disabled personas into a search for all of them, so it is guarded withis not Noneand there is a test pinning it.No delete method
do_requestdispatchesGET,POSTandPATCHand raisesValueErroron anything else, soDELETE /agentpersonas/{id}is not reachable from this client. Adding it means teachingdo_requesta new verb — out of scope here, and no caller needs it yet.Testing
6 new tests, 37 total passing, matching the existing mock-the-Session style: each asserts both the parsed return value and the exact URL and payload sent.
Ran the three CI jobs locally against a fresh
poetry install --no-root:No dependency changes, so
poetry.lockis untouched.Follow-up
yeti-platform/yeti-agents#12 is held pending this: once released, it drops the private-attribute access and the hand-built endpoint constant in favour of these methods.