Custom AI Employees
An AI employee built for one role in your business
We define the responsibilities, train the employee on approved company knowledge, write your rules as code, connect the systems the role needs, and deploy it with permissions, escalation and human oversight. Every engagement starts with discovery. There is no self-serve signup.
What we build
Six system types, one architecture.
Select a category to see its typical inputs, actions and outputs.
Internal knowledge agents
Answer questions from your approved company files, policies and databases — citing the source and respecting who is allowed to see what.
Typical inputs
- Policy documents and handbooks
- Internal wikis and knowledge bases
- Structured records with access rules
Actions
- Retrieve the relevant passage or record
- Reason across it against the question asked
- Check the asker's permission scope
Outputs
- A cited answer, or an escalation when scope is exceeded
- A log of what was asked and what was returned
Document & data agents
Extract, classify, compare, validate and route information from forms, PDFs, emails and spreadsheets into the systems that need it.
Typical inputs
- Scanned or digital forms and PDFs
- Inbound email and attachments
- Spreadsheets and legacy exports
Actions
- Classify document type
- Extract and validate structured fields
- Compare against existing records
Outputs
- Structured data written to a system of record
- Exceptions routed for review
Workflow agents
Watch for an event, decide against your business rules, call the relevant APIs, create or update records, notify people, and wait for approval where required.
Typical inputs
- An event: a form submission, a status change, a schedule
- Business rules and thresholds
Actions
- Evaluate the event against the rules
- Call APIs to act
- Create, update or notify
Outputs
- Updated records in your systems
- Notifications and, where scoped, a pause for human sign-off
Research & analysis agents
Search approved sources or connected datasets, reason across larger volumes of material, surface correlations, and produce a report that shows its working.
Typical inputs
- Approved external or internal sources
- Connected structured datasets
Actions
- Search and retrieve across sources
- Compare, cross-reference and reason
- Draft findings against a brief
Outputs
- A traceable report with sources cited
- Flagged items needing human judgement
Operational AI employees
Handle intake, follow-up, case or status updates, scheduling, triage and internal service requests as part of day-to-day operations.
Typical inputs
- Incoming requests across channels
- Calendars, case systems and status fields
Actions
- Triage and prioritize
- Draft or send follow-ups
- Update case or ticket status
Outputs
- Updated cases and calendars
- Fewer requests waiting on a person to pick them up
AI-powered applications & portals
A custom interface — a dashboard, client portal, admin panel, search or chat experience, or reporting tool — built around one workflow.
Typical inputs
- The workflow the interface needs to expose
- Roles: staff, admin, client
Actions
- Present the relevant data and actions per role
- Surface approvals, edits and overrides
Outputs
- A working interface your team or clients use directly
- An audit trail of actions taken through it
Not every engagement includes every capability above — a build is scoped to the categories the problem actually calls for.
What makes an employee custom
Not a template — a role assembled from what your business actually needs.
A custom AI employee can draw on any combination of the following, scoped to the work in front of it.
Proprietary business logic and exceptions
Your policies, thresholds and edge cases are written as code and configuration, not inferred by a model at run time.
Custom code
Where a task needs deterministic behaviour — a calculation, a validation, a formatting rule — it is built as code, not left to language-model judgement.
Larger approved datasets, retrieval and structured search
Indexing and retrieval designed for your volume of documents or records, not a single prompt window.
API and database connections
The system reads and writes inside the tools you already run, instead of operating beside them.
Multi-agent or multi-step orchestration, where useful
Some problems split cleanly into stages handled by different agents or steps; we orchestrate that only where it earns its complexity.
Role and permission boundaries
What the system can see and do is scoped per role, matching who is allowed to see or approve what today.
Human approval gates
Steps that carry risk or require judgement pause for a person to approve, edit or reject before anything is final.
Custom application UI
Where staff or clients need to interact with the system directly, we design and build the interface for that specific workflow.
Activity logs, failure handling and monitoring
Every run is logged, failures are caught and surfaced rather than silently dropped, and behaviour is visible after launch.
System anatomy
Eight layers — what ScoChat configures, what you control.
Every build is assembled from the same layered architecture. Each layer names the work our engineers do and the decisions that stay with you.
Inputs & data sources
Where information enters the system — files, forms, emails, records, events.
ScoChat configures
- Parsers and connectors for each source format
- Validation and error handling on intake
Client controls
- Which sources are in scope
- Who is authorized to submit or approve intake
Knowledge & retrieval
How approved material is indexed and made searchable so the system can find the right passage or record.
ScoChat configures
- Indexing, chunking and retrieval design
- Search and ranking tuned to the content
Client controls
- Which documents and databases are approved for use
- Update cadence as source material changes
Model & reasoning
The language model or models used to interpret input and draft a response, matched to the task.
ScoChat configures
- Model selection and routing per task
- Prompting, guardrails and output structure
Client controls
- Risk tolerance for automated judgement calls
- Where reasoning must defer to a rule instead
Custom rules & code
Deterministic logic — your policies, calculations and exceptions — that the model does not get to improvise.
ScoChat configures
- Implementation of business rules as code
- Edge-case handling agreed during discovery
Client controls
- The rules and exceptions themselves
- Sign-off on how edge cases should resolve
Tools & APIs
The connections that let the system act — reading and writing inside your existing software.
ScoChat configures
- Integration build and authentication
- Rate limits, retries and failure handling
Client controls
- Which systems may be connected
- Access scopes and credentials issued
Human review
The points where a person approves, edits or rejects before an action is final.
ScoChat configures
- Approval-gate implementation and routing
- Escalation paths when confidence is low
Client controls
- Which actions require sign-off
- Who is the approver for each gate
Application & dashboard
The interface staff or clients use to see and interact with the system.
ScoChat configures
- Interface design and build
- Role-based views and permissions
Client controls
- Who gets access, and to what
- Workflow priorities the interface should surface first
Logs & measurement
The record of what the system did, and whether it is moving the agreed baseline.
ScoChat configures
- Activity and audit logging
- Reporting against the agreed baseline
Client controls
- Retention and access to logs
- Which metrics count as success
What you receive
The deliverables, named.
Scoped per engagement — this is the full list a build can draw from.
Discovery & workflow map
A documented map of the process as it actually runs today, including exceptions.
Value & current-state baseline
What the process costs today, agreed as the measurement baseline.
Solution architecture
The layered design: data, reasoning, rules, integrations, review and interface.
Approved knowledge & data plan
Which sources are in scope, how they are indexed, and who can access what.
Custom development
The agent, workflow logic and business rules, built and tested.
Integrations & API work, as scoped
Connections into your existing systems, built to least-privilege access.
Interface or dashboard, where required
A purpose-built UI for the people who need to see or act on the system's work.
Permissions & human-control design
Role boundaries and approval gates matched to who is accountable for what.
Test plan, edge cases & acceptance testing
Testing against real cases, agreed and signed off before launch.
Deployment & operating documentation
How the system runs, what to do if it fails, and who owns what.
Training & handover
Your team knows how to operate, monitor and escalate on day one.
Monitoring, maintenance & iterative improvement
Ongoing per the agreement reached at scoping — not assumed as a default.
Delivery process
How a build actually moves through the stages.
Each stage names what we need from you to keep moving.
Discovery
We learn the process, the people involved and the systems it touches.
Needs · Access to the people who do the work today
Process, data & integration audit
We document the current state, the data available and what needs to connect.
Needs · Sample data, documents and system access for review
Solution design & scoped proposal
We propose the architecture, the scope and the commercial terms.
Needs · Sign-off on scope, budget and success measures
Prototype
A working prototype against real examples, not a mockup.
Needs · Feedback on the prototype against real cases
Integration & custom development
The full build: rules, integrations, interface and controls.
Needs · Credentials and technical points of contact
Testing with real edge cases
We test against the exceptions that actually occur, not just the happy path.
Needs · Edge cases and historical examples to test against
Controlled launch
A scoped rollout with monitoring and an easy path to pause or roll back.
Needs · A named owner for the system after launch
Measurement & optimization
We report against the baseline and tune the system as real usage comes in.
Needs · Ongoing feedback from the people using it
Engagement and pricing
Priced after discovery — not before it.
There is no public fixed package. Pricing is agreed once we understand the problem, and reflects:
- Workflow complexity
- Number and difficulty of integrations
- Data volume, data quality and retrieval requirements
- Custom code and interface requirements
- Security and permission requirements
- Testing and rollout scope
- Ongoing usage, hosting, monitoring and support
- Expected value: time saved, cost removed, capacity created, revenue enabled or protected
Commercial structure may combine implementation, an ongoing managed service or usage component, and — where appropriate — a value or outcome component. We never guarantee ROI.
Fit
Whether this is the right engagement.
Not the right fit if
Where we would say no
- The problem is unclear and has no owner on your side
- You cannot provide access to the data or systems involved
- The expectation is unattended, high-risk decision-making
- A simple task is already solved well by standard software
Right for you if
Where a custom build earns its cost
- The process is repetitive or data-heavy
- Generic tools cannot express your rules
- The work spans systems that need to talk to each other
- The value at stake is measurable
- Your team can provide access to the relevant subject matter
FAQ
Common questions about custom development.
Is this a chatbot?
Sometimes a chat interface is part of the build, but the underlying system is usually a workflow, an agent acting inside your tools, or an application — not a standalone chatbot.
Can it use our private data?
Yes, within sources you approve. Access is scoped per engagement and per permission boundary — it does not have blanket access to everything you hold.
Can it connect to our existing systems?
Yes, that is typically part of the build. Integrations are scoped during discovery against the specific systems and APIs you use.
Do you build the user interface too?
Where a workflow needs one, yes — a dashboard, portal, admin panel or reporting view is part of the deliverable, not a separate product.
Can a person approve actions?
Yes. Human approval gates are designed into the workflow wherever a decision needs sign-off before it becomes final.
How long does a project take?
It depends on scope — the number of integrations, the data involved and the testing required. Timeline is agreed after discovery, not before it.
Who owns the custom work and data?
This is governed by the proposal or statement of work agreed for each engagement. You retain your data; licensing and IP terms for the custom work are agreed in writing.
What happens after launch?
Monitoring, maintenance and iterative improvement continue per whatever is agreed in the engagement — this is not assumed by default and is scoped explicitly.
How is it priced?
Pricing is agreed after discovery and reflects complexity, integrations, data requirements, testing and expected value. We never guarantee ROI.
Can it use large datasets or big data?
Yes — retrieval, indexing, structured queries or analysis are designed to the dataset and the use case. Not every model ingests everything at once, so the approach is matched to volume and structure.
Consultation-led
Design your custom AI employee.
Bring the process that costs you the most time or money. We will map the architecture and the baseline we would measure against.