Develop aApps

If you plan to build or customize aApps, follow this approach:

  1. Define capabilities first, then design UI

    1. Start by defining the problem, target users, and expected output.
    2. Design semantic actions (for Agent invocation) before building UI.
    3. Avoid overbuilding pages and buttons too early, which increases complexity and reduces composability.

  2. Make interfaces Agent-friendly

    1. Use clear, action-oriented naming.
    2. Keep parameters concise and consistent.
    3. Design for composability so multi-step workflows can be chained reliably.

  3. Build a minimum viable loop first
    Prioritize this baseline loop first:
    User request → Agent calls aApp → aApp returns a usable result
    After this loop is stable, expand to advanced capabilities such as subscriptions, automation, and richer UI.

  4. Separate retrieval from answering

    1. Use retrieval-oriented capabilities when you need structured candidates (IDs, metadata, machine-processable outputs).
    2. Use answer-oriented capabilities when you need direct user-facing responses.
    3. This separation improves reliability, interpretability, and performance.

  5. Design event automation as a full pipeline
    Subscription is not just a trigger. A robust flow should include:
    Trigger condition → Context enrichment → Analysis/processing → Write-back/feedback
    This ensures automation consistently delivers value instead of only “firing events.”

Developer-Friendly Design in remio

  1. DEV / PROD environment isolation

    1. DEV is for development, debugging, and testing.
    2. PROD is for stable daily usage.
    3. Code and data are isolated, so tests do not contaminate production usage.

  2. Visual environment switching

    1. DEV/PROD status is visible in navigation and easy to switch.
    2. This supports safe, iterative development.

  3. Dual entry points: Skill Market + Skill Studio

    1. Skill Market: discover, install, and manage available skills.
    2. Skill Studio: clone, modify, and test-publish skills.
    3. “Use” and “build” are clearly separated, lowering adoption cost.

  4. MCP integration: low barrier + high flexibility

    1. Supports quick OAuth-based onboarding and manual setup (stdio / streamable-http).
    2. Works for both fast adoption and advanced integration scenarios.

Developer Tips

  • Validate thoroughly in DEV before switching to PROD.
  • Introduce one external dependency at a time (e.g., one MCP server) for easier troubleshooting.
  • Reuse existing Skills/aApps first, then apply incremental customization.
  • For any automated flow, add failure fallback and visible user feedback.