Why AI Portal
One governed entrance to AI for the whole company — agent-first chat with department budgets, model allowlists, audit and per-resource sharing, running inside your own AWS account.
eCloudvalley (ECV) builds the AI Portal as a repeatable enterprise product for AWS-centric organisations. It installs into a new AWS account without customer-specific code: Bedrock-first, deployed into your account, with governance that is enforced — not just displayed.
Key rules
- Agent-first chat. You always talk to an agentAgentAgentAn assistant with its own instructions, knowledge, tools and default model. Every chat runs through one — plain chat is an agent that used no tools.Open in glossary; a plain answer is an agent turn that used no tools.
- Department budgets. Every request is billed to exactly one department, whose budget has an alert point and a hard stop.
- Model allowlists. Departments block the models they give up; everything else in the catalogue stays open.
- Audit per model call. Every call leaves an audit row with its cost.
- Per-resource sharing. Agents, skills, prompts, connected apps, artifacts and knowledge bases each carry their own allow and deny rules.
What success looks like
A deployment is working when two things are true at once:
- Employees run a useful workflow — for example a research workflow — through a governed agent.
- Administrators can prove who used which model, under which policy, at what cost.
The problem it solves
AI adoption usually starts bottom-up: each department buys its own consumer AI subscriptions. It works — until someone asks where the data went, what it cost, or who still has access.
| Problem | What it looks like | What the portal does |
|---|---|---|
| No governance | Data goes to whichever provider an employee picked, with no allowlist, no common policy and no reliable audit trail | One model allowlist, one policy, and an audit row for every model call |
| No cost control | Spend is split across subscriptions and cards, with no attribution, rate limit or enforceable ceiling | Department budgets and rate limits, with an alert point and a hard stop |
| No identity lifecycle | Access does not follow corporate single sign-onSingle sign-on (SSO)Đăng nhập một lần (SSO)Signing in once with your company account, such as Entra ID or Okta. The portal never sees your password.Open in glossary, provisioning and offboarding | Sign in with your company account; people are added and removed automatically through SCIM |
| No shared leverage | Useful prompts, knowledge, workflows and outputs stay in individual accounts | Agents, skills, prompts, knowledge and artifacts become governed company resources |
Principles
Every architecture and scope decision is checked against these eight principles.
| # | Principle | What it means |
|---|---|---|
| 1 | Agent-first | You chat with an agent that may use instructions, skills, knowledge, memory, tools and MCP applications. A plain answer is an agent turn that called no tool |
| 2 | Enforced below the screen | The portal explains policy; Keycloak (sign-in), the portal’s API layer, LiteLLMLiteLLM (model gateway)LiteLLM (cổng mô hình)The gateway every model call passes through. It routes to Bedrock, applies each department's key and budget, and records the cost of every call.Open in glossary (the model gateway) and the agent layer enforce it |
| 3 | Bedrock-first | A model call to Amazon Bedrock stays inside your AWS account. A provider key that a department or a person pastes reaches that provider |
| 4 | Your account, your deployment | One organisation per deployment, running inside your own AWS account. Every deployment is built from the same code and templates, so nothing is written specially for one customer |
| 5 | One admin surface | Your administrators work in the portal. The LiteLLM and Keycloak consoles are ECV break-glass only |
| 6 | Configuration defines an agent | One parameterised agent host runs every agent configuration. Creating an agent deploys nothing |
| 7 | Clear progress, clean answer | Thinking summaries, tool activity, approvals and clarifications render as a working timeline. Only the final answer renders as the answer |
| 8 | Refresh keeps the run | History is durable, and an active run reconnects without duplicating what is already on screen |
Who it’s for
There is no team-level owner, admin or user tier — administrators manage the whole organisation.
| Person | What they need | Start here |
|---|---|---|
| Employee (Org User) | Chat with allowed agents, attach files, reuse prompts, get cited answers, manage personal memory and see their own quota and budget | Use the portal |
| Org Admin (built-in role) | Organisation settings, users, departments, groups, roles, model access, budgets, visibility, tools, applications and the audit log. No billing control | Administer |
| Org Owner (built-in role) | Full organisation control, including billing.manage and moving people between built-in tiers | Administer |
| Custom-role holder (for example Cost Analyst or Compliance Reviewer) | A narrow bundle of capabilities — such as reading spend or reviewing the audit log — assigned directly or through a group, without becoming an Org Admin | Roles and capabilities |
| ECV operations (eCloudvalley) | Provision, upgrade, observe and recover a customer’s deployment; break-glass access to the provider consoles when required | Deployment |
What you get
The product covers two surfaces.
- Streaming agent chat with history, search, folders, attachments and prompt insertion
- Tool activity, citations and artifacts
- Structured clarification questions
- A working timeline kept separate from one final answer
- Runs that resume after a refresh
- Execution modes for connected apps: Ask before each action or Run without asking
- Discovery limited to the resources you may see
- Your own usage and budget state
- Management of your personal memory
- Keycloak brokering Entra ID, with SCIM provisioning
- Direct department membership
- Many-to-many groups and capability roles
- A model catalogue with one row per model
- LiteLLM virtual keys, budgets and rate limits
- Per-resource allow and deny visibility, with an effective-access preview
- An immutable audit row for every model call
- Usage, cost and chargeback reporting
What it isn’t
- A multi-cloud product — it is built for AWS only.
- One runtime per agent — every agent is configuration on one shared host; no service is deployed per agent.
- A team hierarchy — there are no team-role tiers and no department-owned resources.
- A native mobile app — it is a responsive web application.
- Not current goals: consumer-chat parity, image generation, a plugin marketplace, or deep ERP/CRM write automation.
Why it works this way
Why deploy into the customer's own AWS account?
Each organisation gets its own deployment inside its own AWS account, so a model call to Bedrock never leaves that account. Because every deployment is built from the same code and templates, a new organisation needs no custom code — just another deployment. See Deployment.
Why is governance enforced below the screen?
A rule that only lives in the user interface can be bypassed by calling the API directly. So the portal’s screens only explain policy: sign-in is enforced by Keycloak, permissions and visibility by the portal’s API layer, budgets and rate limits by LiteLLM, and tool rules by the agent layer.
Why does creating an agent deploy nothing?
An agent is a configuration bundle — instructions, model, tool allowlist, knowledge and skill references — that one shared, parameterised host loads per run. Creating, editing or sharing an agent is a database change, not an infrastructure change.
Why is only one admin surface offered?
Customer administrators do everything in the portal’s Admin console. The gateway (LiteLLM) and identity (Keycloak) consoles stay closed to them and are opened only by ECV in a break-glass situation, so policy is never changed behind the portal’s back.
