One Partner Agent between business context and cross-company commercial action.
Vinculo recognizes commercial opportunities in approved signals, matches existing relationships, and helps the relationship owner prepare or execute the allowed action. People decide only where the rules require.
Source systems know the customer and context. Vinculo knows the commercial relationships, rules, and possible actions. A bounded source-derived state may be enough; richer context is used only as scoped and approved.
The executable relationship
This governs what Vinculo may do when a recognized opportunity makes an existing relationship relevant.
The Partner Agent is the product boundary, not one unrestricted AI model. AI recognizes needs and opportunities; the relationship layer governs authority; bounded tools execute.
Signal
Use the minimum context required: an approved structured event, a source-system-derived state, or richer approved context for a defined purpose.
Opportunity
Recognize a commercial need from a bounded source-derived state or interpret approved context when needed. Preserve provenance and confidence before relationship matching.
Relationship
Match the opportunity to an existing relationship and capability. Its rules govern applicability, economics, permission, action, and expiry; AI cannot grant authority.
Permission + authority
The relationship defines what data may be used, what can be disclosed, what Vinculo may execute automatically, and which actions require employee approval, manager approval, customer consent, or human-only action.
Action + execution
Vinculo prepares or executes the allowed step in the existing workflow. If authority is missing, it surfaces only the required decision.
Verification + outcome
Vinculo confirms what actually happened, writes the state back, reconciles failures, and learns from verified outcomes.
What AI does, and what people and rules decide
AI interprets approved context and variability. Deterministic, auditable relationship rules determine authority; people decide only where required.
- Interpret scoped, approved context or use bounded source-derived states
- Synthesize events across delivery, billing, CRM and document metadata
- Recognize commercial needs and opportunities before relationship matching
- Generate human-readable reasoning and evidence summaries
- Which commercial relationships are approved
- Which destinations are eligible for a given need
- Which fields may be shared, and with whom
- Which actions execute automatically and which require approval, consent, or human-only action
- Whether an opportunity already exists, and whether to suppress
Cross-company actions fail. Vinculo preserves what happened, retries what it can, and escalates only the unresolved exception.
Failure detected → preserve completed state → retry or alternate route where allowed → record unresolved state → escalate only if human access, judgment, or action is required.
Decision logic for complex signals
When a need is spread across several approved sources, this is how Vinculo reaches a permitted action
1. Connect to approved context
- Receive an approved structured event or a derived state from a source system with trusted access to its own context
- When needed, interpret approved structured, unstructured, or composite context; broad access is not the default
- Read-only or scoped access where appropriate, limited to a defined commercial purpose
- Record provenance and the limits on what may be observed separately from what may be disclosed
2. Derived commercial state
- Use a source-system-derived commercial state when sufficient, or interpret approved evidence into a state when needed.
- Tie the derived state to the right customer without defaulting to a duplicate customer-data warehouse.
- Preserve source provenance and confidence without automatically forwarding raw context.
3. Commercial opportunity recognition
- A source system may detect the state in its trusted environment and send only that state; source-side classification is one supported pattern, not a requirement
- Vinculo recognizes the commercial need or opportunity in a bounded state, defined event, or approved richer context before matching any destination
- Evidence is grouped as primary, supporting, or corroborating
- Need/opportunity recognition is not destination fit or authority. Relationship rules determine permission; people decide only where required.
4. Need confidence
- How much independent evidence supports the need
- Partners can set their own evidence rules
- Low confidence stops the process before any destination is considered
5. Approved commercial relationships
- Which existing relationship and destination capability fit the recognized need or opportunity, and which accounts are eligible.
- Permission, authority, consent and data rights, economics, permitted action, and destination live in the executable relationship.
- Verification and expiry or revocation rules bound each relationship.
- AI may recognize relevance but cannot create commercial authority.
6. Destination fit
- Is this destination actually a good fit for the need?
- Use Strong / Possible / Weak.
- A real need can still result in no action if the fit is weak.
7. Permissions and partner rules
- Observation and disclosure are separate permissions; only the minimum permitted information moves.
- What executes automatically; what requires employee or manager approval, customer consent, or human-only action.
- Which actions are allowed.
- The partner can override or stop an action.
- Access to data and permission to act are not the same thing.
8. Destination pipeline check
- Check whether the destination already has an active account or opportunity.
- Avoid creating duplicate activity.
- Suppress the action if the opportunity already exists.
9. Prepare and manage the action
- Prepare or execute the allowed action; bring in the relationship owner only where required.
- Track whether it executed, was received, was changed, or stopped.
- Avoid sending the same action twice.
10. Deliver into the partner's workflow
- When a person is required, surface only the missing decision where they already work.
- This could be CRM, email, Slack, Microsoft Teams, or another workflow.
- The employee should not need to monitor a separate Vinculo inbox.
- The delivery method can vary by partner.
11. Send the action to the destination
- Check the destination's existing pipeline.
- Send or create the approved action.
- Get enough outcome information back to know what happened.
- Salesforce and HubSpot are examples of destination systems.
12. Track what happened
- Was the referral accepted?
- Was an opportunity created?
- Did the meeting happen?
- Did the opportunity move forward?
- Tie the outcome back to the original Vinculo action.
13. Learning and suppression
- Capture why a partner approves or dismisses something.
- Turn repeated feedback into clearer rules.
- Hold back similar actions when a partner has already shown they are not useful.
- Explicit partner knowledge can override inferred context.
Data boundary
Minimum context for detection; minimum disclosure for action
- Prospect identity
- Partner identity
- Approved need summary
- Approved commercial context
- Partner-approved message
- Raw CRM notes
- Full project details
- Source documents
- Emails and call transcripts
- Unrelated customer records
Prefer an approved event or derived state when sufficient. Richer context may be used only as approved for the defined purpose. Observation is not disclosure: identity and commercial details move only as far as the relationship permits; raw source context does not automatically go to the destination.
One decision, many delivery options
- Partner A → CRM card
- Partner B → Microsoft Teams
- Partner C → email
- Partner D → CRM task
Connect once, activate more existing relationships: approved signal access and opportunity recognition can be reused, while each relationship keeps its own rules and delivery workflow.
Destination reuse is also a hypothesis: a shared Salesforce connector should make later destinations primarily authentication, mapping, permission, and workflow configuration. Bespoke integrations for every destination would materially weaken the economics.
What Vinculo does not require
- No default duplicate customer-data warehouse
- No purchased third-party intent data
- No customer identity moves before the relationship rule allows it
- No invented deal values
- No action taken outside the relationship rules