Creating AI agents: build your own agents without code | meinGPT
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.
For Department leads, AI champions and IT — even without a development team.
- 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
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.
From the task to productive AI use
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.
- 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 All departments gets done with AI
Concrete, repeatable flows — from the first prompt to a dependable result.
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.
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.
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.
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.
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).
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.
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.
A real prompt, a real answer
Nothing hidden — you see the input and the result before you sign up.
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.
| Building block | Recommendation 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 |
| Knowledge | Data pool: product catalogue, price list, text-block collection (RAG) |
| Tools | Charts (calculation), optionally a CRM connector to create the quote |
| Guardrails | Sending/writing only after human approval; scope limited to released CRM objects |
| Model | "Best model" or a strong reasoning model for clean calculation |
Put it to work in your own company
In a short live demo we show how this solution runs in your company with meinGPT, GDPR-compliant — using your own use cases.
Or get the practical guide by email:
A work email is enough — processed in line with the GDPR.
Built for enterprise compliance
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.
- 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?
What this solution cannot (yet) do
Honesty is part of the solution. These limits are known — and therefore plannable.
An agent is only as good as its instruction and its knowledge base — without a clean system prompt and maintained sources, answers stay generic.
Actions in third-party systems are limited by the permissions and scopes granted; the agent can only trigger what it has been cleared for.
Results and actions with legal or financial effect (quotes, contracts, bookings) must be reviewed and approved professionally before use.
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.
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.