The Second Project: Running an AI Agent for Real Users

---

Your team built an agent, and it works. The demo was convincing; the pilot went well. Then someone asked the operating questions: who signs in, who pays for each conversation, where do the files go, what happens when two hundred people use it at once, and how do we ship next month's version without breaking this one?

That is the second project. It is larger than the first, it is invisible on the original plan, and it has nothing to do with how clever the agent is.

01 What the second project actually contains

• Identity and access. Real users sign in; scoped runtime services bind conversations, files, and budgets to the current user and app; outside automations get their own revocable grants instead of borrowing a person's.
• Money. Covered paid steps — including model, embedding, and web-search calls — are checked and reserved before they run, then settled and attributed after. Custom services can join the same accounting contract.
• Company accounts. The agent can work with mail and chat through accounts each user explicitly connected. The live service catalog defines the action, the selected account carries its provider permission, and credentials stay server-side and revocable instead of becoming one shared company token.
• Conversation continuity. Ordered lanes serialize one conversation across workers. A hosted run-to-completion agent receives everything pending at turn start as one invocation, while its own transcript and the platform's reloadable record preserve different kinds of memory — including an accepted request whose turn later fails.
• Code the agent writes. In the reference split profile, generated code runs in a separate networkless executor with narrow mounts. Approved real operations cross to a trusted supervisor under the current identity and policy.
• Evidence. Configured subsystems emit attributable operational records: actor, authority, covered cost, result, and failure. They support review; retention and integrity policy determine whether they satisfy an audit.
• Shipping. New versions deploy without a rebuild of the product around them; one tenant/project-scoped deployment serves many trusted apps and many users concurrently.

Each line above is months of engineering when built in-house — and all of it is undifferentiated: your users chose you for the first project, never the second.

02 The part your team keeps

The agent your team built stays. The framework it uses — LangGraph, CrewAI, the Claude Agent SDK, or your own code — stays. The product's interface and business services stay. The runtime surrounds that work with the operating layer, and adoption starts at a single seam: host the existing agent behind one interface, or move one risky capability into confined execution, and stop there if that is all you need this quarter.

That gradual shape is what de-risks the decision. There is no migration cliff, no rewrite, and each step pays for itself before the next one starts.

03 What it means for the business

• Time to market. The second project comes off the roadmap; the team ships product features instead of plumbing.
• Predictable spend. Budgets are enforced before actions run and attributed per person for covered calls; custom or unintegrated spend remains the application's responsibility.
• Audit readiness. Runtime records provide reviewable evidence. The deployment's retention, integrity controls, and review process determine audit suitability; the runtime is not a compliance certification.
• No lock-in. KDCube is self-hosted and open source, MIT licensed. It runs on your infrastructure; the operator chooses the app code, model providers, integrations, and egress paths that may handle data. You retain the runtime, app source, configuration, and deployment-owned stores.

· Read the full story

This brief is the executive layer of a deeper piece — the architecture, the adoption paths, and what the runtime enforces at each boundary: