Features
Everything it takes to turn an outcome into an application.
Hosted Applications connected to your services and your data, a place to keep their records, and your people opening them in a browser. Below is what Ekaya does, and how each part works.
Hosted Applications
What your builder and AI deliver, your people just open.
Your builder's AI builds the application and publishes it. Your people sign in and use it in a browser. A dashboard should be a dashboard, not a conversation. Dashboards, forms, and trackers are first-class ways to run a business.
Business overview
Weekly orders
- Orders
- 128
- +17% vs last week
- In progress
- 24
- 6 shipping today
- Follow-ups due
- 7
- 3 due today
- Repeat customers
- 41%
- +4 pts
Orders per day
Illustrative orders per day this week compared with last week.
Orders by source
- Google Ads46%
- Meta Ads31%
- Direct23%
Customers to follow up
- Due today
Northwind Supply
Quote sent, 3 days ago
- This week
Alder & Finch
Reorder window opens Friday
- Due today
Kestrel Studio
Delivery question open
- This week
Bright Dental
No reply since last order
How it works
- 1
Build with your agent.
Connect the data your business uses. Have your coding agent build the interface and author the Queries and Actions it needs. You approve what it can do.
- 2
Publish in Ekaya.
Your agent publishes the application and gets its URL. The first version starts with Administrator-only access. Then open it to selected Roles or everyone in the Project.
- 3
Your people open it.
Members sign in and open their applications. Each data request runs as the person viewing the app, under their Role's permissions.
- 4
Keep improving it.
Publish updates from your AI tool or switch back to a stored version. Updates become current for existing viewers immediately. Restoring a version changes the app files; it does not undo data changes.
- No agent needed to use one.
- Members need no Claude Code, MCP client, or AI subscription. Application access and MCP access are independent.
- The application acts as its viewer.
- It reads and acts through approved Requests under the signed-in person's identity and Role. Permission to open an application does not grant permission to run additional Requests.
- Hosting has a boundary.
- Ekaya hosts the browser applications an agent builds. The browser runs the application's JavaScript; Ekaya is not a general-purpose server or background job runner.
One connection
600+ services via one Ekaya connection.
Instead of installing every service into your AI tool, connect it to Ekaya once, and Ekaya manages the services and datasources your business already uses. Have internal services or need a custom connector? Your builder's AI can create it, and Ekaya hosts it with the application.
And hundreds more.
SaaS, inverted
Every service holds a piece of your business. The outcome needs all of them.
Ad campaigns running in multiple channels. Customers in your database. Nowhere to attach marketing acquisition to product activation. Instead of pulling value out of each service one screen at a time, connect them to one Ekaya Project. Their APIs come to your builder's AI, and the application it builds works across all of them. Each service keeps its data model. It loses its monopoly on the screen.
The question: Which campaigns bring in qualified customers?
Illustration. Separately, Google Ads shows Fall Roast with 412 conversions and Gift Box with 230; Meta Ads shows Morning Ritual with 380 and Cart reminder with 190; the customer database knows which of 1,212 customers qualified but not which ad brought them in. Together, in one application: Morning Ritual 45% qualified, Fall Roast 30%, Cart reminder 20%, Gift Box 10%.
Connect your AI to Ekaya once, then ask. How it works
Datasources
Connected to the services and data your business runs on.
A Project uses the datasources its work requires. There are two kinds, and they are equals: the operational databases and warehouses a business runs, and the systems it depends on.
Two kinds of datasource, equals in one Project.
Illustration. Database datasources: PostgreSQL and its family, SQL Server, BigQuery, and the Managed Project Database. Databases you connect are read in place and never copied into Ekaya. Service datasources: ad platforms, CRMs, support desks, vendor portals, and internal services. Credentials never pass through the agent; a person enters them on a page built for that act.
How it works
- 1
Ask your agent to connect it.
Name the database or the service. The agent does the setup.
- 2
Enter the credentials yourself.
A person enters them on a page built for that act. They never pass through the agent.
- 3
Ekaya holds the schema.
Every datasource has one: discovered for databases, declared for services.
- 4
The agent writes Requests over it.
It authors the Queries and Actions an application needs, and you approve what it can do.
Managed Project Database
Somewhere to keep records.
Where enabled, a Managed Project Database gives applications and agents a place to keep their own records. A Project may start with an application and its own database, or use an existing warehouse and need no new database at all. Ekaya Solo includes a free Managed Project Database.
Database levelsA check-in form saves a visit, into the Project's own database.
Illustration. A dog groomer's check-in form books a visit for Biscuit, a full groom on Thursday at 10:30. The form saves it through a Request, as the signed-in person, and the new row lands in the visits table of the Managed Project Database, under the same Requests, schema, and audit as any other database.
How it works
- 1
The application asks to save.
A form or a tracker calls a Request, as the person using it.
- 2
Their Role decides.
The Request runs only if the signed-in person's Role permits it.
- 3
The record lands in the database.
The Managed Project Database keeps it, in the Project's own schema.
- 4
It is on the record.
The same Requests, schema, and audit apply as to any other database.
Requests
Queries read. Actions change.
Every datasource sits behind the same contract: approved, parameterized Requests, reachable over MCP and HTTP.
Two example Requests, and the three ways an Action can end.
Illustration. A Query named overdue_wholesale_customers reads customers with no order in the last N days, takes a days parameter, may be run by the Sales Role, and returns at most 100 rows. An Action named send_reorder_reminder emails one customer a reorder reminder, takes a customer_id, may be run by the Sales Role, and is limited to 25 a day. An Action ends in one of three ways: succeeded, definitely failed, or indeterminate, where Ekaya cannot tell, records what was attempted, and never repeats it silently.
How it works
- 1
The agent authors a Request.
It defines the operation, its parameters, who may run it, and its limits.
- 2
A person approves it.
For an Action whose effect is uncertain, they first attest what it does.
- 3
A caller supplies parameters.
An agent or an application sends validated parameters, never open-ended authority.
- 4
It ends one of three ways.
Succeeded, definitely failed, or indeterminate. Ekaya never silently repeats an ambiguous Action; it gives the application the evidence to decide.
- Approved Requests are the endpoints.
- Each is reachable over MCP and HTTP, and each defines its operation, parameters, permissions, and limits. A Query cannot change data; an Action is named as one.
- Administrators get the sharp tools.
- An Administrator can run ad-hoc queries through their agent and author new Requests. Exposing ad-hoc tools to a Project's other agents is a deliberate, recorded choice.
Questions, not SQL
Connect your database. Ask it, in your own words.
Connect PostgreSQL, SQL Server, or BigQuery as a datasource. It stays where it is: connecting a database does not copy it into Ekaya. Your AI reads the schema and proposes what each table and column means in your business. You approve those definitions once. After that, ask your AI ad-hoc questions the way you would ask a colleague, like which wholesale customers are overdue for a reorder, and the answer comes from your databases and/or connected services, using the definitions you approved.
An ad-hoc question: in the roaster's own words, answered from the roaster's database.
Illustration. In Claude Code, the roaster asks which wholesale customers are overdue for a reorder. Each term has a meaning a person approved once: wholesale customers are customers whose channel is wholesale, overdue means no order in the last 30 days, and a reorder is any order after a customer's first. The answer comes from the roaster's PostgreSQL database, in place: Parlor Café, last order Sep 2, 34 days; Hillside Bakery, Sep 4, 32 days; The Reading Room, Sep 5, 31 days.
Meaning
Answers that are correct, not lucky.
Every datasource has a schema, and every column carries its role, its semantic type, and its sensitivity. A model can propose what the data means. Only a person can make it so.
A table's columns, each carrying its role, its meaning, and its sensitivity.
Illustration. The orders table. customer_id is an identifier for the customer who placed the order, channel is a dimension for where the order came from, and total is a measure of order value in dollars; all three meanings are approved. email is an attribute, how to reach the customer, marked sensitive, and its meaning is proposed and waiting for a person to approve it.
How it works
- 1
The agent reads the schema.
Discovered for a database, declared by a service.
- 2
It proposes what things mean.
A column's role, semantic type, and sensitivity, the business meaning and glossary behind the data, or a relationship between two sources. Ontology Forge helps extract them.
- 3
A person approves it, once.
Nothing a model guessed becomes a definition until someone signs off.
- 4
Every agent inherits it.
The next agent to ask starts from the approved definition, not from its own guess.
People and processes
Who is asking, and on whose behalf, is always on the record.
Roles and Members decide what each person may reach. Data Access Points give a process an identity of its own.
One person's reach, and the record one request leaves.
Illustration. Maya Chen has the Sales Role. She can open the Orders dashboard and run overdue_wholesale_customers and send_reorder_reminder, but not refund_order, which her Role does not include. Opening an application grants no additional Requests. The record of one request reads, in order: human Maya Chen, agent Claude Code, request send_reorder_reminder, parameters customer_id c_1042, data touched one row of customers, policy decision allowed, response reminder sent, approval approved by Sam, Administrator.
How it works
- 1
A person signs in.
To open an application, or to connect their agent.
- 2
Their Role sets their reach.
Each Role defines what its people may reach. Removing access takes effect without waiting for a session to end.
- 3
The request runs as them.
Their agent acts on their behalf, and their Hosted Applications act as them.
- 4
The record is written.
Every request records who asked, on whose behalf, and what happened.
- Roles and Members.
- Members are the people on a Project, and each takes a seat. Administrators are Members with elevated privileges: they connect their AI, the datasources, and the applications, and every Administrator is a builder. Each person's Role defines what they may reach. Their agent acts on their behalf and their Hosted Applications act as them.
- Data Access Points.
- The identity a process holds — an agent, a worker, a scheduled job, or an external application's backend — each with its own permitted Requests and an attributable audit trail.
How it works
Connect your AI to Ekaya once, then ask.
- 1
Create a Project in the Ekaya Cloud console. Creating it is your act; no agent creates a Project for you.
- 2
Connect your AI coding tool to that Project's MCP server once, and sign in. The Project's Setup page gives you the steps for the client you use, with the Project's own MCP URL.
- 3
Ask for the outcome. Your AI clarifies it, does the setup, and hands a person only the acts that are theirs, such as completing a service sign-in.
Install the MCP Server
Run in your terminal on the machine where you use your agent.
claude mcp add --transport http ekaya https://mcp.ekaya.ai/...- Start or restart Claude Code in your project.
- Run
/mcp, select ekaya, and authenticate in your browser.
If Claude Code reports that ekaya already exists, run claude mcp remove ekaya in the same project before adding the new connection.
The server entry is named ekaya. To switch Projects, update or replace that entry with the other Project’s connection. Your credentials are entered during browser sign-in.
Example URL. Your Project's Setup shows these steps with its own MCP URL.
Then the Project's MCP server guides your AI through the build.
Setup in an example Project, as the Project's MCP server guides your AI through it. Your agent is connected and the outcome is recorded.
- You enter the customer database's credentials.
- Your agent selects the schema.
- You approve two Requests, both Queries.
- You sign in to Google Ads, and your agent publishes the connector.
- Your agent publishes the app, Campaign retention, as a private Hosted App that only you can open until you open it to others.
Questions
- What is Ekaya?
- Ekaya enables AI to deliver business outcomes. Describe the outcome your business needs. Enlist AI and the people who can build it. The result is a hosted application, connected to your services and data, that is still there after the chat closes and that your people open in a browser. Free for one person.
- Can Claude Code build business apps, dashboards, and internal tools?
- Yes. Claude Code builds and publishes business apps, dashboards, and internal tools; Ekaya Cloud hosts them, and your people open them in a browser. Start with the outcome your business needs, then ask for the dashboard, form, or tracker that delivers it.
- Does my team need Claude to use the apps?
- No. What your builder and AI deliver, your people just open. They need no Claude, no coding agent, and no AI subscription. They sign in and use the application in a browser.
- What does it cost?
- Ekaya Solo is free for one person. Adding a second Member, someone to open the result or a second builder, requires Ekaya Team at $20/month. Includes 3 seats. Additional seats at $5/month. The Billing Owner adds the card and approves what the Project buys. The offer belongs to the Project.
- How do I connect Claude Code?
- Create a Project in Ekaya Cloud, then add its MCP server to Claude Code once with: claude mcp add --transport http ekaya <the Project's MCP URL>. Replace the placeholder with the MCP URL from that Project's setup page; each Project has its own URL. Then ask for the outcome.
- Does Claude get my passwords and keys?
- No. A person completes any service sign-in in a flow built for that act, separate from the coding agent's setup and from the work a request does. The sign-in never passes through the conversation.
- Can everyone see everything?
- No. Each person uses an application within their own Role. An application acts as the person viewing it, and permission to open it grants no additional Requests.
- Can Claude change things by accident?
- An Action, a request that changes something, is named as one and approved by a person before it can run.
- What if a write fails halfway?
- Ekaya reports success, failure, or indeterminate honestly. It never invents a failure to make a retry look safe.
- Can I see what happened?
- Every request records who asked, on whose behalf, and what happened.
- Does it copy my databases into Ekaya?
- Connecting an existing database or service does not copy it into Ekaya. Ekaya holds what you deliberately ask it to host: application files, business records, configuration, knowledge, policy, and audit. Connected-source results are not kept as a replay cache.
Enterprise ready
Supercharge your business.
You know AI can accelerate your business, but are large pilots going nowhere? Give employees the power to create their own applications. Ekaya Enterprise is the answer: the same platform, inside your organization's own boundary, in your cloud, hybrid, or on-prem, built and installed with you rather than shipped to you. Builders deliver outcomes with their own coding agent, as applications that run in your sandbox, and their co-workers just open them, without IT bottlenecks. Sign-in comes from your identity provider, each application acts as the person using it, and your data and services stay where they are. All data access is governed, tracked, and auditable through the air-gappable Ekaya Gateway.
Built and shared by employees: three applications, seven people, one boundary.
Illustration. Inside one organization's boundary, three employees built applications with their coding agent and shared them with co-workers: Amara Osei in Procurement built a carrier scorecard that runs in the cloud, used by Rosa Kim in Procurement and Lior Adler in Finance; Jonas Lindqvist in Operations built a shift handoff that runs across your cloud and your data center, used by Dev Mehta, a depot lead; Mei Tanaka in Finance built an invoice exceptions app that runs on-prem, used by Lior Adler and by Sofia Nunes in accounts payable. Inside the boundary, people sign in with the organization's identity provider, each application acts as the person using it, and Ekaya, the data, and the services stay there.
Start with the outcome. Everything else follows.
What outcomes can your business ask for?How do I build business apps with Claude Code?Where do I host an app Claude Code built?How do I share what Claude Code built with people who have no Claude or coding agent?How do I connect Claude Code to Google Ads, Meta Ads, and my own database?