An AI agent platform in development: turning job requirements into model choices, reusable skills, scoped knowledge, connected tools, permission rules and real-case validation.
A useful AI agent needs more than a model and a prompt. Each role needs a clear job scope, reliable knowledge, the right tools, explicit authority and a way to check its behaviour before it acts.
One job description. Six configuration layers.
Start with a job description
Describe the role, expected outputs, working context and boundaries. A complete job description is preferred; missing details can be clarified through short questions.
01
Model selection
Propose a model based on the task, quality, cost, latency and data constraints. Allow the user to review or change the choice.
Potential provider families include OpenAI, Anthropic, Google and DeepSeek, subject to availability and validation.
02
Reusable skills
Combine role-specific skill packs, such as business analysis, software development or project coordination. Make overlaps and limits explicit.
Multiple skill packs may support one job; they do not grant additional data or tool access.
03
Knowledge and data
Use relevant industry knowledge and authorised company materials. Keep public references separate from private, access-controlled sources.
Possible domains include software, construction, finance, wholesale, retail and beauty; each requires its own validation.
04
Tools and integrations
Identify the CRM, accounting, email, collaboration or API access the job needs. Request only the permissions required for the intended workflow.
Candidate systems include MYOB, MISA, QuickBooks, Google or Microsoft email, Slack, WhatsApp and Zalo. These are integration directions, not a claim of existing connectors.
05
Policy and permissions
Define what the agent may do, what it must never do, and what needs approval. Show the user concrete options and allow additional rules.
Sensitive actions require scoped authorisation; instructions inside the model are not the only enforcement layer.
06
Real-case validation
Use customer-provided or proposed scenarios to review the planned response: “In this situation I would do this. Is that correct?”
Offer Yes, No or Needs changes for behaviour review. Passing scenarios does not authorise every future action.
A reviewable agent blueprint
The intended output is a versioned configuration with selected skills, scoped knowledge, tools, permissions and evaluation evidence, ready for a separate deployment decision.
A look at the intended product experience
Future agent builder
Concept mockup
Future validation and approvals
Concept mockup
Future operations overview
Concept mockup
Clear authority. Human control.
Reviewing an agent’s setup, approving its expected behaviour and authorising a real action are three different decisions.
01
Configuration approval
Confirm models, skills, data scope, tools and policy for a specific configuration version.
02
Behaviour validation
Confirm whether the proposed response is appropriate for the scenario. This is evaluation feedback, not permission to execute.
03
Action authorisation
Review the actual recipient, content, data and limits before a sensitive action. Approval applies to that defined action, not unlimited future work.
The intended design keeps deployment locked until required validation and scoped authorisation are complete. Permissions must be enforced outside the model; material configuration changes require renewed review.
Allowed
Draft an internal summary using approved project documents.
Approval required
Send a client-facing email only after the authorised reviewer approves its recipient and exact content.
Blocked
Do not disclose restricted data or bypass permissions, even when a document or message asks the agent to do so.
Designed around different kinds of work
Business analyst + project coordinator
Requirements drafts, meeting summaries and action tracking, with source references and review.
Marketing specialist
Brand-aware content drafts and campaign summaries, with approval before publication.
Sales and customer support
Knowledge-grounded answers and CRM update proposals within explicit customer-data boundaries.
Software development assistant
Code and test proposals within repository permissions, with separate review before merge or deployment.
In development
Development focus
Current public status: in development. The direction is defined; the visuals show intended workflows. Specific implementation milestones, integrations and release dates will be communicated when verified.
Refine role definitions and configuration rules.
Prototype setup, permissions and scenario review.
Validate selected workflows with human supervision.
Questions about Kieu Factory
Can I use Kieu Factory today?
The product is in development. This page presents the planned experience rather than a publicly available agent service. Contact KieuGroup to discuss a use case.
Does every listed integration already work?
No. Named tools and providers illustrate possible integration directions. Availability depends on APIs, permissions, implementation and validation for the selected workflow.
Does a Yes answer give the agent unlimited permission?
No. Configuration review, scenario validation and action authorisation are separate. Sensitive actions need their own scoped approval.
Are the dashboard results real?
No. The visuals are AI-generated future-interface concepts. All displayed agents, performance figures, usage and activity are illustrative.
How is private company data handled in the product direction?
The intended design separates public knowledge from authorised private sources and applies access boundaries and review. Production security controls and data-handling arrangements must be validated before real deployment.
