feat(conversation): add ConversationReadOptions with includeSkills#172
feat(conversation): add ConversationReadOptions with includeSkills#172simonrosenberg wants to merge 1 commit into
Conversation
The agent-server's conversation routes now accept an optional ``?include_skills=false`` query param that drops ``agent.agent_context.skills`` from the response payload (see software-agent-sdk#3316). Default behaviour on both sides is unchanged — full payload — so existing clients see no regression. Expose the opt-in through the typed client: - New ``ConversationReadOptions`` interface with ``includeSkills?: boolean`` - ``getConversation``, ``getConversations``, ``searchConversations``, ``createConversation`` all accept it as an optional trailing arg - ``buildConversationReadParams`` maps the camelCase TS shape to the snake_case wire form (``include_skills``); omitted fields aren't sent so older agent-servers behave as before The bytes-on-the-wire delta is meaningful: a stock ``load_public_skills=true`` agent inlines ~260 KB of skill content into every ``ConversationInfo`` response. Clients that don't read skill bodies (agent-canvas's conversation list, for example) can now opt in to drop that without bypassing the SDK. Tests cover the default-omitted behaviour (param absent from URL), opt-in serialization on every endpoint that accepts it, and that ``includeSkills`` is correctly translated to ``include_skills`` on the wire (and never leaks as ``includeSkills``).
|
Closing this for now — the agent-server-side opt-in lands as software-agent-sdk#3316, and there's no current rush to wire it into the typed client. The change here is correct and ready when needed — anyone wanting the typed Until then, agent-server's default response shape is unchanged, so existing consumers (agent-canvas, |
|
Reopening as a draft. Per follow-up discussion: no rush to ship — the goal is to keep this validated and pinnable to a SHA so the downstream canvas opt-in PR can prove the typed code path works (CI / linting / runtime profiling) without waiting on a release. Will land properly once software-agent-sdk#3316 merges and ships a release that canvas can pin to. |
1 participant
Exposes the
include_skillsquery parameter that software-agent-sdk#3316 adds to the conversation routes. Pure addition — no behaviour change for existing callers.Why (revised — for the legacy opt-in)
The companion SDK PR was reframed as a breaking change: the agent-server now trims
agent.agent_context.skillsfrom conversation responses by default, since no known client reads the field from HTTP. Callers that still need the legacy full-payload shape can opt back in with?include_skills=true.This client change exposes that opt-in cleanly via a typed
ConversationReadOptionsinterface, so the rare legacy caller doesn't have to bypass the SDK helper with a rawHttpClientto set the flag. Steady-state usage (default trimmed shape) needs no change at this layer.What
ConversationReadOptionsinterface withincludeSkills?: boolean.getConversation,getConversations,searchConversations, andcreateConversationall accept it as an optional trailing argument.include_skills) via a small helper; omitted / undefined fields are not sent.Tests
Five new cases in
api-clients.test.ts:getConversationscall omitsinclude_skillsfrom the URL (server default applies — trimmed shape on new agent-servers, full shape on older ones).getConversationsopt-in sendsinclude_skills=truefor legacy callers.getConversationendpoint.searchConversationsmergesincludeSkills→include_skillstranslation with other search params.createConversationforwards the param as a query string even though it's a POST.33/33 tests pass on
api-clients.test.ts. Build is clean.Companion PRs
agent-canvas#651— closed; canvas doesn't read the field and needs no change once the new SDK ships.Status
Draft until the SDK release lands. Low-priority since most callers will never need it — kept for completeness and so legacy integrations don't have to bypass the typed SDK layer.