Bring context into the workspace without losing control.
Connectors are the path for bringing outside context into Ethen where supported. The workspace should show what was referenced, what boundaries apply, and when approval is needed. The page focuses on the trust model for connected context: what was brought in, what stayed outside, what approval was required, and how that context shaped the result. That is more useful than a long list of names without clear boundaries.
Context movement with visible boundaries.
Model work is only useful when it has the right context. Connected context stays useful when access is visible, scoped, and reviewable. Ethen Connectors are framed as a controlled way to bring supported systems into the workspace while preserving context boundaries, approval paths, and evidence. Connected systems become valuable when they make model work more grounded. They become risky when context arrives invisibly or without a clear record. Connectors are therefore framed as scoped context paths rather than vague integration magic.
- Bring context from connected systems where supported. Scoped context is easier to trust than broad implied access.
- Show what sources were referenced in a run. Reference visibility helps users understand what influenced the answer.
- Use approvals for sensitive or state-changing connector actions. Approval matters because some outside systems contain sensitive or consequential data.
- Keep connector behavior tied to evidence and workspace history. Connector boundaries should be visible before the workflow depends on them.
- Leave room for a future connector ecosystem without inventing availability. Where support exists, the value comes from context quality and control together.
Connector capabilities
Connectors should make context useful without making access feel uncontrolled. The important question is not only whether a source can connect. It is whether the resulting context remains understandable and controllable.
Context access where supported
Bring authorized context into the model workspace from connected systems when a connector is available and configured. Context should enter the workspace with enough structure to be reviewed.
Reference visibility
Show which sources, files, records, or systems were referenced so users can inspect the model's context path. Reference records matter because users often need to retrace the source of an answer.
Approval boundaries
Pause before sensitive reads or state-changing actions where approval is required by policy or workflow design. Approval boundaries help keep sensitive data movement deliberate.
Connector evidence
Attach connector activity, references, and results to workspace history so the run remains reviewable. Scoped access reduces the chance that a connector feels broader than intended.
Workflow context
Let repeatable workflows request the context they need without hiding connector behavior inside a prompt. Evidence matters because connected context can change the meaning of a result.
Future ecosystem direction
Support reusable connector patterns over time, with listings, logos, and availability reflected through current product surfaces and documentation. Connector patterns are stronger when they support real workflows instead of isolated demos.
How connector context works
The connector path should make context clear before it affects a model result. A connector should make context clearer, not blur where it came from.
The workspace requests context
A user or workflow identifies the outside context needed for the task. Start with the source the workflow actually needs.
The connector boundary is checked
Availability, permissions, and policy boundaries determine what can be referenced. Make the referenced context visible before it shapes the output.
The source is surfaced
The workspace shows the referenced source or source type where visibility is available. Apply approval where the data movement is sensitive.
The model uses allowed context
The model receives the permitted context through the workspace rather than unrestricted access. Keep evidence of what was used and when.
Evidence stays attached
References, outputs, approvals, and connector activity can stay connected to the workspace history. Return the connected work to the broader workspace with its boundaries intact.
Visibility and control
Connector trust depends on what the user can see and approve. Trust in connectors comes from visible scope, visible references, and visible approval rules.
Referenced context
Show what connected context influenced the work where the connector supports visibility. Users should not have to guess whether a system was consulted.
Permission boundaries
Make access limits and approval needs visible instead of implying broad access. Scope awareness makes connector behavior easier to reason about.
Human approval
Require explicit approval before sensitive or state-changing connector actions. Approval rules help limit surprising data movement.
Workspace evidence
Keep connector results and references attached to the output for review. Evidence helps future reviewers understand why a result looked the way it did.
What this page represents
This page explains the connector direction for bringing context into Ethen with visibility and control. It is not a fixed integration catalog. It intentionally avoids claiming a fixed catalog or universal availability. The public value is the controlled context model, not an inflated inventory.