Practice

All departments · Use cases

Creating AI agents: build your own agents without code

What an AI agent is (and how it differs from an assistant and a chatbot) and how companies build their own AI agents without programming: goal, instruction, knowledge (RAG), tools & actions, guardrails and approval — with a build guide, an example, governance, a checklist and GDPR.

Request a demoGo to the platform
Who it is for
Department leads, AI champions and IT — even without a development team
Impact
From a click to a working agent in minutes instead of weeks — built by the departments themselves, without a release cycle
Task
Build your own AI agents without code — from the goal through knowledge and actions to team release
What it is about

What this use case delivers.

An AI agent is an AI assistant configured for one concrete task, bundling three building blocks: an instruction (what it should do), connected knowledge (which documents and data sources it can access) and tools (which actions it may perform in other systems). The difference from a simple chatbot: a chatbot answers questions from a fixed script or general model knowledge; an assistant additionally answers with evidence from your own company context; an agent goes further — it calls tools, searches sources and works through a multi-step task independently until the goal is reached. In a company an AI agent is not programmed but assembled through an interface — by the department itself, without a line of code.

How it works

You build an AI agent without code by defining five things in an editor. First the basics: name, icon, description and the AI model — either automatic "best model" or a specific model per agent. Second the instruction (system prompt): role, task, context and answer format in natural language — ideally structured into clearly separated sections, because that produces noticeably better results than running text. Third the knowledge: upload individual files or connect a pre-indexed data pool (RAG search index), so the agent answers from your own company knowledge rather than generically. Fourth the tools: built-in tools (calculation, web search, charts, code), live connectors to services such as Microsoft 365, Google Workspace, Jira, Confluence, HubSpot or Salesforce, your own MCP servers for internal specialist systems, plus read access to databases — each so the agent does not just talk but triggers real actions. Fifth the guardrails: permissions, scopes and how many tool calls the agent may make per answer. The finished agent is tested, shared with the team and managed centrally — without a deployment and without a release cycle.

Concrete workflows

These steps are part of the implementation.

These recurring tasks can be covered with the same underlying pattern.

01

Step 1 — define the goal and the role

Before building, the task is described precisely: which recurring activity should the agent take on, what result does it deliver, and who uses it? From this goal come the name, icon and a description that colleagues without prior knowledge can understand — the agent's basic identity.

02

Step 2 — write the instruction (system prompt)

The main lever: role, task, context and answer format are defined in natural language — no code. A structure of clearly separated sections (## Role, ## Task, ## Rules) has proven better than running text. Tools in use are mentioned explicitly in the prompt, otherwise the model often does not use them.

03

Step 3 — connect knowledge (RAG)

The agent gets access to static company knowledge: individual files by upload for manageable amounts, or a pre-indexed data pool (RAG search index) for larger bodies of knowledge. The agent then answers with evidence from your own context — access follows the permissions granted.

04

Step 4 — activate tools and actions

This is where an assistant becomes an agent: built-in tools (calculator, charts, web search, code sandbox), live connectors to services such as Microsoft 365, Google Workspace, Jira, HubSpot or Salesforce (send an email, create a ticket), your own MCP servers for internal systems without a ready-made connector, and read access to databases for reporting. The agent thereby triggers real actions.

05

Step 5 — set the guardrails

So the agent may only do what it should: scopes are set per tool — permitted folders, labels, calendars or teams (allowed) plus sensible defaults. Critical write operations are additionally limited through method policies, and the assistant mode governs how many tool calls the agent may make per answer at most (default: up to 5).

06

Step 6 — test and sharpen

The agent is checked against real examples in a test chat; an assistant check reports live whether the instruction, description, tools and knowledge sources are set. An "improve" step optimises the prompt (structure, completeness). Iteratively, without a deployment — until answers and actions are reliably right.

07

Step 7 — release and manage

The finished agent is released to the right people, managed centrally and adjusted or revoked as needed. That turns a one-off solution into a repeatable team tool — and everyone works with the same quality-assured agent instead of inconsistent individual prompts.

Example

Input and result side by side

Input

Build me the specification for an AI agent called "Sales Quote Assistant". Goal: turn a short description of an enquiry into a structured quote. Give me concretely: (1) a finished system prompt with the sections Role, Task, Rules and Answer format, (2) which knowledge sources I should connect (product catalogue, price list, text blocks), (3) which tools/actions make sense, and (4) which guardrails I should set so the agent sends nothing without review.

Result

Building blockRecommendation for the agent
Role (prompt)"You are a quoting assistant for the sales team."
Task (prompt)Turn an enquiry description into a quote with line items, totals and a covering letter
Rules (prompt)Actively ask for missing quantity/discount; prices only from the data pool; tone: professional, concise
KnowledgeData pool: product catalogue, price list, text-block collection (RAG)
ToolsCharts (calculation), optionally a CRM connector to create the quote
GuardrailsSending/writing only after human approval; scope limited to released CRM objects
Model"Best model" or a strong reasoning model for clean calculation
Next step

Implement it in your company

In a short demo, we clarify data, ownership and the right workflow for this use case.

Book a live demo

Or get the Practical guide by email:

Security and selection

AI agents run inside the central platform governance. Access to knowledge sources follows the permissions granted; actions through tools are limited per connector by scopes (permitted folders, labels, calendars or teams) and critical write operations additionally by method policies. Admin approvals at tool level, the creation, sharing and revocation of agents, and all access run centrally through SSO and are logged. The operator is SelectCode GmbH, which is ISO 27001 certified and has its security reviewed regularly through independent penetration tests (most recently SySS, 2025). The platform is operated in the EU, a data processing agreement (DPA) is standard, and company input is not used to train the models — so control over data and triggered actions stays inside the company and can be evidenced to data protection officers, the works council and auditors.

What to check when choosing a solution

  • No-code: Can agents be assembled by departments in the editor without programming?
  • Knowledge connection: Can the agent use files and larger bodies of knowledge (a RAG data pool) — filtered by permissions?
  • Actions: Are real actions in third-party systems possible (native connectors, custom MCP, databases) — or is it chat only?
  • Guardrails: Can access per tool be limited through scopes (permitted folders, labels, teams) and approvals for critical write actions?
  • Governance: Central management, roles & permissions, audit logs and revocation of agents?
  • Model choice: Can the right model be chosen per agent, instead of being tied to one vendor?
  • Shareability: Can finished agents be reused across the team and adjusted in operation?
Known limitations

What needs to be clarified before rollout.

These points need to be clarified professionally or organisationally before rollout.

  1. 01

    An agent is only as good as its instruction and its knowledge base — without a clean system prompt and maintained sources, answers stay generic.

  2. 02

    Actions in third-party systems are limited by the permissions and scopes granted; the agent can only trigger what it has been cleared for.

  3. 03

    Results and actions with legal or financial effect (quotes, contracts, bookings) must be reviewed and approved professionally before use.

  4. 04

    Complex, multi-step agents need testing and iteration in the test chat — the first draft is rarely the final one; more tool calls also cost more time and credits.

  5. 05

    Scope enforcement is still partly tool-specific — for reliable limits, scopes and method policies should be set and validated once per tool in the test chat.

Frequently asked questions

Through an editor, without programming: you set the basics (name, model, description), write an instruction (a system prompt with role, task, rules, answer format), connect knowledge (files or a RAG data pool), activate tools and actions (built-in tools, connectors, custom MCP, databases) and set guardrails (scopes, approvals, maximum tool calls). The agent is then checked in the test chat, released and shared across the team — without a release cycle.

More practical content

See pricingSecurity and hostingPractical guide