What is Pact?

An account establishes the tenant boundary. A person's membership connects them to that account; workspaces organise the resources they can reach. A role or grant determines the actions permitted within that reach.

An agent operates in this same environment with a durable identity and an accountable owner. A run identifies one execution of its work. The delegator and grant explain why that run can act and where its authority stops.

Authentication identifies the actor; authorisation determines whether the requested operation is permitted. Product APIs apply that authority at the resource being accessed, rather than treating a successful sign-in or an available tool as permission for every action.

1. Sign in. A person signs in to your application with their own identity.
2. Join an account. Membership connects the person to their organisation and its tenant boundary.
3. Enter a workspace. Workspace access puts the right resources within reach.
4. Act with permission. Roles and grants determine which actions the person can take.

People, accounts and workspaces form one connected access journey. Each account keeps its own data and membership.

• Act for a person. A user delegates a task to an agent. Its grant limits the resources, actions and duration of that work, and the record identifies both the user and the agent.
• Act for an organisation. An organisation-owned agent works under an explicit mandate with an accountable owner. Its authority does not depend on a person keeping a session open.
• Delegate a smaller task. Future direction An agent gives a specialist a narrower child grant. The specialist can use only the authority delegated to it, with a traceable connection to the parent task.

Agent

The durable identity of the software actor carrying out a task.

Owner

The person or organisation accountable for an agent and its lifecycle.

Run

One execution of an agent's work, distinct from its durable identity.

Delegator

The person, organisation or parent agent that gives authority for a task.

Grant

The permitted resources and actions, bounded by conditions and duration.

Illustrative concept · Support agent · Northstar account · fictional example

1. StartedActor: Support assistant · owner: Northstar support team · run: Ticket review 42.
2. ApprovedDelegator: Alex · tenant: Northstar · grant: read assigned tickets and draft a reply.
3. CompletedRead ticket 1042 inside the permitted workspace. Decision: allowed; outcome: ticket retrieved.
4. CompletedDraft a reply to ticket 1042. Decision: allowed; outcome: draft saved for review.
5. RefusedRead another tenant's records. Decision: outside the grant; outcome: no records returned.
6. RefusedDelete the ticket. Decision: action not granted; outcome: ticket retained.
7. RefusedSend the reply. Decision: separate authority required; outcome: draft remains unsent.

1. Establish ownership. Connect a person or agent to an account and accountable owner.
2. Delegate. Identify who requests the work and whose authority it uses.
3. Grant access. Bound permitted resources, actions and duration.
4. Change access. Update membership and grants as responsibilities change.
5. Review actions. Trace the actor, tenant, grant, decision and outcome together.

Identity and authority follow the work from ownership through delegation to review.

Connect your product's sign-in experience to accounts, workspaces and permissions. Pact supplies the identity and tenant model; your application owns its screens, routing and business behaviour.

Each adopting platform runs its own configured Pact APIs against its own database. Your identity configuration and data stay with your platform, while product APIs enforce the authority required for each resource and action.

Bring your agent environment into the same account and workspace model. Pact connects an agent's identity, delegation and grant to the actions your product permits; your runtime owns execution, prompts and tools.