Why AI workflows need governed data access
Tool calls let agents touch data. Business workflows need more: governed Projects, durable work product, attached datasources, approval gates, DDR, and audit trails over what agents create.
Agents executing real business workflows do not just ask questions. They inspect context, build ontology, write intermediate state, coordinate across runs, and eventually produce work that may need to be written back somewhere else.
That work needs a governed data access interface designed around the workflow. In Ekaya, the workflow starts as a Project. The Project gives agents an isolation boundary, durable work product, and the datasources they need to read from or write to.
The Project is the unit of governance
A human admin creates the Project when a workflow needs governed agent access to data. Permissions, approvals, audit trails, and deployment choices all attach to that Project instead of being scattered across one-off tools.
The Project is where agents work
A Project has Postgres-compatible storage for scratchpad state, workflow state, schema, ontology, and durable work product. The admin governs and approves what changes become part of the workflow.
Datasources stay attached, not absorbed
Datasources are the external databases and artifacts agents need for the workflow. Their ontology often lives outside Ekaya, so a human SME may need to answer domain questions. Ekaya does not replace those systems; it gives agents a governed access boundary around them.
Deployment follows residency
Some Projects can run in Ekaya's cloud where the customer boundary permits it. Others need Ekaya Engine because the workflow data must stay inside the customer boundary. That is a data-residency decision, not a separate product story.