TASIP-007: Self-extending TAS

[ryw]

Status: Draft — open for input · Category: Big bet

Summary

Point your instance at your own fork so a Tembo coding agent can build the platform extensions you need — a new connection type, a custom substrate — and PR them back, staying upgrade-safe with upstream. High-touch teams get deep integrations without waiting on the core roadmap.

Why

TAS can't ship every specialized capability every customer needs. Because TAS is itself a codebase a coding agent can edit, a customer's fork can grow the platform the same way their agents grow — by PR — instead of filing a feature request and waiting.

Sketch

• A workspace can target its own fork of TAS for platform-level changes.
• A Tembo coding agent makes the change (e.g. a non-standard OAuth provider) and PRs it into the fork.
• Staying in sync with upstream releases keeps the fork upgrade-safe.
  (Provisional — the shape changes based on the discussion.)

Open questions

• Where's the line between "agent change" and "platform change"?
• How do forks take upstream updates without painful merges?
• What guardrails keep a self-extending instance maintainable?

How to help

React 👍 if you want this, and comment with your use case, constraints, or pushback. This is a draft Tembo Agent Studio Improvement Proposal (TASIP); your input shapes it before it becomes scheduled work.