Airo Agent Skills and Connectors v2 Plan

Date: 2026-06-20

Goal: Bring the Google AI Edge Gallery style Agent Skills experience into Airo: skill manager, enabled skills, on-device model skill selection, native connector execution, and visible action traces in chat. The first end-to-end connector should be calendar read/create because it proves permissions, private local data access, multi-step tool use, and final natural-language response.

Current Airo baseline: agent_chat already has deterministic intent parsing, a small ToolRegistry, GoRouter navigation, Gemini Nano fallback chat, and Gallery-inspired prompt cards. That is useful but not the same architecture as Gallery skills. The v2 work should add a real skill runtime between chat and tools.

Product Shape

Build one Airo feature called Agent Skills inside the Assistant tab.

Architecture

1. Skill Package Model

Add a package format that is compatible with the Gallery mental model but native to Airo:

calendar-today/
  SKILL.md

SKILL.md contains YAML frontmatter plus instructions:

---
id: calendar-today
name: calendar-today
description: Read today's calendar events and summarize the user's schedule.
version: 1.0.0
author: Airo
runtime: native
capabilities:
  - calendar.read
tools:
  - get_current_date_time
  - read_calendar_events
---

# Calendar Today

Use this when the user asks about today's schedule, meetings, agenda, or calendar.
First call `get_current_date_time`.
Then call `read_calendar_events` with `date` in YYYY-MM-DD.
Summarize events by time. If no events exist, say there are no events scheduled.

Add these Dart models:

Recommended location:

2. Skill Repository

Add a repository that returns enabled built-in skills first.

Phase 1 should avoid remote/community installation. Remote skills introduce supply-chain and prompt-injection risk, so they should be behind a later review gate.

Recommended files:

Store user enable/disable state with the app’s existing local persistence pattern once that is clear. If no stable app storage exists, start with an in-memory repository plus tests, then persist in the next task.

3. Connector Registry

Add a separate connector layer. This is the main difference from the current ToolRegistry.

ToolRegistry currently routes known intents to screens or simple deterministic responses. Connector registry should execute app-owned native operations:

abstract interface class AgentConnector {
  String get name;
  Set<SkillCapability> get requiredCapabilities;
  Future<ConnectorResult> execute(Map<String, dynamic> arguments);
}

Built-in connectors for phase 1:

Recommended files:

4. Calendar Connector

Use a real calendar plugin for mobile builds.

Preferred package for read and write: device_calendar.

Reason: it supports requesting calendar permissions, retrieving calendars, retrieving events, adding/updating/deleting events, recurring events, reminders, attendees, and timezone-aware start/end dates.

Alternative for create-only flows: add_2_calendar.

Reason: it launches the native calendar app for user confirmation and does not need special permissions by default for the basic create flow, but it is not enough for “check my schedule” because Airo must read events.

Required platform work:

Safety behavior:

5. Skill Orchestrator

Add an orchestrator that turns a user message into a bounded tool loop:

user prompt
  -> enabled skill summaries
  -> model chooses skill or says no skill
  -> app loads selected SKILL.md
  -> model emits one JSON action
  -> app validates tool name and schema
  -> app executes connector
  -> model receives connector result
  -> repeat until final response or max steps

Use LLMJsonParser for structured responses. Do not rely on free-form text parsing.

Suggested JSON contract from model to app:

{
  "type": "tool_call",
  "skill_id": "calendar-today",
  "tool": "read_calendar_events",
  "arguments": {
    "date": "2026-06-20"
  }
}

Final response:

{
  "type": "final",
  "message": "You have two events today: 10:00 AM Standup and 3:00 PM Design review."
}

Guardrails:

Recommended files:

6. Chat UI

Match the Gallery interaction but keep Airo visual style:

Recommended files:

7. System Prompt Strategy

The system prompt should be assembled by code, not hand-edited in a settings modal.

Use three layers:

  1. Fixed runtime rules:
    • choose skills silently
    • output JSON only for tool steps
    • never invent connector results
    • do not claim actions were performed unless the app returned success
  2. Enabled skill summaries:
    • id, name, description, declared tools
  3. Selected skill instructions:
    • loaded only after load_skill equivalent

This keeps Gemini Nano context small and reduces prompt injection risk from skill text.

8. Initial Built-In Skills

Ship these first:

After calendar is stable:

Implementation Tasks

Task 1: Skill Domain and Parser

Task 2: Built-In Skill Repository

Task 3: Connector Registry

Task 4: Calendar Native Integration

Task 5: Skill Orchestrator

Task 6: Chat UI

Task 7: Remote/Community Skills Later

Acceptance Criteria

Calendar demo should work like this:

  1. User: “Check my schedule for today.”
  2. Airo selects calendar-today.
  3. Airo asks calendar permission if needed.
  4. Airo action card shows:
    • Load calendar-today
    • Execute get_current_date_time
    • Execute read_calendar_events with { "date": "YYYY-MM-DD" }
  5. Airo responds with a concise schedule summary or “No events scheduled.”
  6. If permission is denied, Airo explains that calendar access is needed and offers to open settings.
  7. No calendar data leaves the device unless the user explicitly chooses a cloud mode later.

Key Decision

Do not expose arbitrary “connectors” directly to the LLM. Expose only app-owned, typed connector methods through a registry, with capability checks, argument validation, permission gating, and visible action traces. That gives Airo the same user experience as Google AI Edge Gallery while keeping mobile privacy and platform permissions under app control.