What is an AI agent?
An AI agent is a system that can take a goal, use available context, and carry out a bounded sequence of actions toward an outcome. A chat interface alone is not necessarily an agent. The distinction matters when an instruction could affect real work: an agent needs clear limits, feedback from the environment, and a way to show what it did.
In Cortera, Kili is the in-product agent that helps build and maintain a workspace. Its job is not to make unreviewable decisions. It translates a request into a proposed interface or workflow change, then works within the workspace’s permissions and validation path.
What is dynamic UI?
Dynamic UI is an interface that can be safely revised in place as the work changes. Unlike a static generated application, it does not treat the first output as fixed. The interface can add a status, refine a workflow, or reorganize a view while retaining the context and data rules that make the workspace usable.
The key difference: dynamic UI is not visual churn. The aim is a controlled change to a shared operating surface, with continuity for the people who rely on it.
How Cortera differs from a static app builder
A static builder usually follows a short path: prompt, code, export. That can be useful for a one-time output, but it moves the burden of future change into a new editing or development cycle. Cortera is designed around intent, software, runtime, memory, and adaptation. The workspace itself remains the place where revisions happen.
That means a follow-up like “show overdue invoices first” is treated as an update to an existing operating environment, rather than a request to re-create an invoice screen from a blank prompt.
Getting started with your first app
Start with a narrow process that already repeats. For an invoicing workspace, explain who sends invoices, what information needs to be recorded, and which questions people ask most often. Ask Kili for the first operating view, then review the model before you invite a broader team.
- Describe the goal and the people using it.
- Approve the initial workspace and its primary fields.
- Ask for one practical change at a time.
- Use the resulting context to refine the next step.
Working with permissions
Permissions answer who can see, edit, approve, or administer a part of a workspace. Start with the least authority a role genuinely needs. In a client CRM, a contributor may update a contact record without being able to change the workspace’s access model. Sensitive permission changes should always be visible and explicit.
Understanding Kili’s safety checks
Kili proposes changes with a safety path around them. Before a proposed edit is applied to real work, Cortera can trial-run it in a shadow copy of relevant data. This sandbox layer is meant to reveal a mismatch before a team has to recover from it. Routine edits are reversible; permission changes are held for confirmation.
This is not a promise that software will never need review. It is a design choice: help people review the meaningful consequence of a change, not just the words of the request.