The AI Control Layer's "Control app integrations" section links to two in-app
documentation pages rather than a blog post — this is that post. Everything below
traces to those pages' own claims (/open-technology-app/docs/ai-control and
/open-technology-app/setup-and-api), which are themselves sourced to inspected app
code, not aspirational marketing.
The capability and control map
OpenTechnologyApp's AI assistant docs separate what's implemented in source from what's planned — a distinction worth taking seriously, since a chat assistant can describe a planned feature fluently without that proving it exists.
Implemented in source:
- Context follows scope. The organization assistant and project-bound memory threads have different scopes. Ordinary organization reads are restricted to the organization; viewer reads depend on ownership. The platform owner has a diagnostic exception. Project-bound context stays limited to its selected project.
- Read and navigate tools. The tool dispatcher can query items, summarize projects, summarize activity, and return navigation. These tools do not create, edit, or delete items, and navigation alone doesn't execute an automation, playbook, or sync.
Feature-gated in source:
- Reviewed project memory. Project memory distinguishes proposals from active, approved entries. Access, sharing, expiry, and the feature flag all matter — confirm availability and permissions in your target account before relying on it.
Configuration required:
- Provider setup and testing. Supported provider paths need suitable credentials and configuration. The admin model preflight disables tools and app data during that check — a successful preflight confirms the vendor connection works, not that every workflow or data boundary behaves correctly.
Planned, not available yet:
- Confirmable AI writes. The canonical proposal for this reserves mutation tools for an explicit design and review of permission checks, confirmation, audit, idempotency, and reversal. A chat request alone doesn't supply this capability today.
- Repository docs inside app chat. The build workflow already links repository docs, generated agent instructions, and proposals together — but the assistant itself doesn't automatically retrieve those repository documents at runtime yet. Its existing knowledge is based on app data, not the repo's own docs.
Setting it up, by responsibility
The setup docs split responsibility across four roles, and mixing them up is a common source of confusion:
- Platform owner — verifies the deployment, provider configuration, and test environment. Hosting and database permissions are separate from app permissions.
- Organization admin — checks supported connection controls, membership, and available features. Organization administration does not grant platform-wide control.
- Project creator or member — starts with synthetic items in an authorized test project, compares an assistant's summary against the underlying items, and checks the project scope before trusting a broader answer.
- Reviewer — repeats the above with a restricted account, checks that unavailable or foreign-project requests are actually denied, and cleans up temporary records and test credentials afterward.
A repeatable four-step setup ties these together: choose a workspace matching the work, assign responsibility (separating project work from organization administration, provider credentials, and local installation), test with separate synthetic data, then verify and clean up.
API access: what's real today, what's proposed
This is the part most likely to get overstated in casual conversation, so it's worth stating precisely:
Available today: authenticated API calls manage projects and items, subject to account permissions and resource access. Browser-originated mutations also require session and request-forgery protection. Legacy API keys, managed by the platform owner, work with selected endpoints — they are not general project-scoped CRUD credentials, and a paid plan's key allowance doesn't change that boundary.
Planned, no release date announced: scoped credentials limited to an organization, selected projects, and allowed actions — with expiry, revocation, and an audit trail. Automations, playbooks, and sync would use the same permission policy through an explicit execution identity. This is a proposed design, not an enabled feature or a plan entitlement today.
If you're evaluating the app for an integration that needs project-scoped, short-lived credentials with an audit trail, that's the planned direction — not something to build against yet.
A small, verifiable way to try this yourself
The app's own docs suggest starting with something checkable rather than open-ended:
"Summarize overdue items in this test project. Show which items support your answer. If the data is unavailable, say so."
Then check the referenced records and scope yourself. If a provider call fails, record the error without pasting secrets into chat. A fluent answer doesn't prove permission checks passed, a write actually succeeded, or that pricing information is current — verify independently rather than trusting the tone of the response.
Why this matters for anyone writing or reading about the app
The temptation with an AI-assisted product is to describe the assistant by what it could do rather than what it does do today. This module's whole discipline — tracing every claim to inspected source, separating implemented from planned, labeling configuration-dependent features honestly — exists specifically to avoid that. If you're evaluating OpenTechnologyApp for AI-assisted work, ask the same question this post had to answer: is this implemented in source, feature-gated, configuration-dependent, or planned? Those are four different answers, and only one of them means "you can rely on this today."