v0.45.0

0.45.0

Features Added

• AI Skills. Stored, versioned procedures the chat AI can apply during a conversation. Authors create a skill plus its first version with Skill.create(name=..., body=..., description=..., accessibility=..., tags=[...]) and add versions in place with Skill.create_version(...). Visibility is private (author-only) or org (every member of the owning org can see it). Authors are auto-subscribed at create time with the latest version pinned; other org members subscribe explicitly via Skill.subscribe() and pin a version for AI auto-invocation via Skill.set_ai_version(n) (or None to keep the subscription but hide the skill from the AI's load_skill tool — manual chip-invocation in chat still works). List skills with Skill.list_for_org(scope=...), where SkillListScope.Personal is "authored or subscribed" and SkillListScope.Org is "org-shared, not authored." Skill names must match ^[A-Za-z0-9_-]+$ so they can be inserted from the chat composer's inline /skill-name[@vN] slash syntax. Skills carry free-form tags for organizational grouping (set at create or via UpdateSkillMetadataRequest.put_tags / remove_tags; Skill.list_known_tags() returns the distinct set visible to the caller).
• Per-session AI skill set. AgentSession.start(available_skills=[...]) accepts an explicit list of AvailableSkillSpec (skill id + optional version) defining exactly which skills the chat AI may auto-invoke for that session, replacing the registry it would otherwise derive from the caller's skill subscriptions. Each entry may reference any org-shared skill or the caller's own private skill, at any version — visibility only, no subscription required — and the caller's per-user ai_version pins are bypassed. One version per skill (duplicate skill_id is rejected). Passing [] gives the session's AI no auto-invokable skills; omitting the argument keeps the existing subscription-derived behavior. The set is resolved once at session start and frozen onto the session, so later subscription changes and skill-body edits do not leak into it. It is session configuration, not a turn trigger — a session still needs a message, goal, or invoked skill to start. Import AvailableSkillSpec from roboto.ai.agent_session.
• Filter Sessions via RobotoSearch.find_sessions (experimental): new generator method on RobotoSearch that iterates Session instances matching a structured query.
• (experimental) Added roboto.domain.metrics module with Metric and MetricDefinition classes for recording and querying time-series metric data. MetricDefinition manages metric schemas. Metric supports inserting individual observations, querying raw data points by time range, and aggregating data into calendar-period buckets (daily through yearly) with sum, mean, max, min, and count.
• Agents (experimental): New roboto.ai.agent package for storing parameterized agent templates that can be invoked against new subjects without re-authoring the request. AgentRecord captures a StartAgentSessionRequest (in a field named request_template) alongside declared TemplateVariable entries. {{name}} placeholders embedded in any string value within the request template are substituted client-side at invoke time via resolve_agent(agent, values). Unresolved required values raise UnresolvedAgentVariablesError; stray values for variables the agent doesn't declare raise UnknownAgentVariablesError. Both subclass AgentResolutionError. TemplateVariableType (STRING, DATASET_ID, DEVICE_ID) carries a UI hint; for typed values, the invoke handler verifies the referenced entity exists in the caller's org and surfaces a RobotoInvalidRequestException if it does not. CreateAgentRequest, UpdateAgentRequest, and InvokeAgentRequest carry the wire payloads for the corresponding /v1/ai/agents routes. extract_placeholders(body) returns every placeholder name referenced in a request body, useful for tools that inspect or validate a template before saving. Access is enabled per organization; contact us to opt your org in.
• StartAgentSessionRequest.visibility (a new SessionVisibility enum: PRIVATE or ORG) controls who can read a session after it is created. It defaults to PRIVATE so a chat started against POST /chats does not leak to the rest of the org until the caller opts in. The agent invoke flow defaults to ORG because agents exist to share workflows across teammates. Import via roboto.ai.agent_session.SessionVisibility (canonical) or roboto.ai.core.SessionVisibility.
• AgentSessionRecord exposes two new fields. visibility (a SessionVisibility) mirrors the value the session was created with. created_from_agent_id holds the id of the agent that produced this session via the invoke flow, or None for sessions started directly through POST /chats. Both are immutable over the life of the session; forks land as PRIVATE with created_from_agent_id=None regardless of the source session's values.
• Custom fields (experimental): Customer-defined, typed schema-extension points on Dataset, Event, Device, Collection, and Session, scoped per organization and Roboto entity type. Org admins define a custom field with CustomField.create(...), specifying its name and one of five types: Number, String, Boolean, Timestamp, or Enum. Once defined, anyone in the org can set or change values for it using the existing entity-create and entity-update methods (Dataset.create, Event.update, etc.). An entity's full set of custom-field values is available on the entity instance via a custom_fields property. Custom fields are the first-class lane for attributes that need to participate in search and sort (search support arrives in a follow-up release); reach for metadata for opaque annotations.