Education

The examples below describe potential use cases. Execution depends on available skills and connectors, customer permissions and qualification in the customer environment.

What the university is asking for

Registration rules change every term. A student asks whether they may come back after two semesters away, and the answer sits in three places at once: the regulations, the exceptions the deanship approved last year, and the student’s own record. Three people are needed to assemble it, and it still arrives after the deadline.

• Answer a student from the regulations that actually apply to their case, with the article attached.
• Tell faculty what a rule change does to their sections before the term starts.
• Find every student a new registration rule touches, and say why each one is affected.
• Explain why the student portal is slow in registration week, with evidence from the servers.

How the work is done

An agent is a model, a set of approved skills, tools and a policy, applied to a scope.

Agents reach your systems through the MCP servers you connect in the console. A token you enter there is sealed, never shown again, and acts only with the permissions your system gives it; a connector that runs on one of your hosts keeps its token in that host's own connector file.

Execution follows the configured host policy. A command can be approved, denied or referred for human review; individual approval depends on that policy.

The portal, the student system and the mail servers run on machines the university already owns. That is where a university starts, and the registration-week question is the one it answers first.

Read-only execution policy is the default on every enrolled host; the full policy is an explicit, per-host choice.

Host investigations show the commands that ran, their exit codes and output, per host.

A host joins the fleet with one install command and an enrollment token; revoking the host unpairs it.

Customer-hosted installations support an identity provider through OIDC with PKCE. Hosted workspace SSO must be confirmed for the agreed deployment.

Customer-hosted deployments use packaged deployment configuration. An offline deployment requires an accepted bundle, local model and disconnected installation tests.