AI Agents
We design and build bounded AI agents — systems that plan and execute a limited, explicitly defined set of actions — with the tool scoping, approval gates, and decision logging needed to run them safely in production, not just in a demo.
- Tool & function-calling design
- Permission-scoped actions
- Human approval gates
- Agent decision & trace logging
- Agent trajectory evaluation
An AI agent, in this context, is a system that plans and executes a bounded sequence of actions through an explicitly defined set of tools — not a chatbot with loosely-scoped plugins, and not an autonomous system with unrestricted access to your systems. North Tech Labs builds these agents around a fixed tool list, permission tiers that separate read-only lookups from state-changing actions, human approval gates on anything irreversible, and logging detailed enough to reconstruct exactly what the agent decided and why, after the fact.
Business challenges this addresses
- A workflow has too many judgment calls for simple rulesThe process branches too often for deterministic rule-based automation to cover, but reviewing every single case by hand no longer scales with volume.
- Nobody can say what the agent would do in an edge caseStakeholders are wary of connecting an AI system to real systems because there's no clear answer to what actions it's actually capable of taking when it encounters something unexpected.
- An existing prototype can call tools but has no boundariesAn internal proof-of-concept demonstrates that an LLM can trigger actions in other systems, but has no permission tiers, no approval step, and no record of why it did what it did.
- A decision can't be reconstructed after the factWhen an automated action turns out to be wrong, there's no trace of which data the system used, what it considered, or why it chose that action over another.
- The process spans multiple systems and several stepsThe task requires checking one system, making a judgment call, and then acting in another, which is more than a single lookup-and-respond pattern but doesn't need full autonomous decision-making either.
Capabilities
- Tool and function-calling design, with strict input/output schemas per tool
- Single-step and multi-step planning patterns, matched to actual decision complexity
- Session and state boundaries so an agent's context doesn't silently persist or leak
- Retrieval-grounded context (RAG) feeding agent decisions from real source data
- An explicit allow-list of callable tools — no open-ended shell, API, or system access
- Separation of read-only lookup tools from state-changing action tools
- Mandatory approval gates before irreversible or high-risk actions execute
- Bounded iteration limits and timeout budgets so an agent can't loop indefinitely
- Trace-level logging of every tool call, its arguments, and the reasoning behind it
- Evaluation datasets that score tool-selection correctness, not just final output
- Adversarial testing against malformed tool responses and conflicting instructions
- Regression evaluation across agent, prompt, and model versions over time
- Confidence- or risk-based escalation to a human reviewer before acting
- Review queues for flagged or low-confidence decisions
- A defined manual override and kill-switch path for any agent in production
- Staged rollout of action authority, starting from read-only and expanding deliberately
Typical solutions
Examples of the kind of systems this service can build — not a list of completed client projects unless stated otherwise.
- Scoped operational agentAn agent limited to a small, explicitly defined set of tools — such as checking a shipment status or looking up inventory — with no ability to call anything outside that list.
- Multi-step workflow agentAn agent that carries out a defined sequence of steps across more than one system, with a mandatory human approval point before any irreversible action executes.
- Triage and escalation agentAn agent that reviews incoming cases against internal data and routes, tags, or drafts a response, without directly modifying customer or financial records.
- Monitoring and threshold-response agentAn agent that watches a data feed or metric and takes a narrow, pre-approved action when a defined threshold is crossed, escalating anything outside that boundary to a person.
- Retrieval-grounded decision-support agentAn agent that combines retrieval-augmented context lookup with a small set of write actions, so its recommendations stay grounded in actual source data rather than model memory alone.
Delivery approach
- 1DiscoveryWe map the specific workflow and list every action the agent might plausibly need to take, then agree which of those require human approval before they execute.
- 2Tool & permission designWe define the exact set of tools the agent can call, their inputs and outputs, and which are read-only lookups versus state-changing actions.
- 3ArchitectureWe choose an orchestration pattern — single-step, multi-step planner, or a bounded loop — sized to the actual decision complexity, with explicit stop conditions.
- 4Evaluation setupWe build a trace-level evaluation set, including tool-failure and ambiguous-input scenarios, before writing production logic.
- 5DevelopmentWe build the agent with every tool call, argument, and reasoning step logged from the start, not added retroactively after an incident.
- 6QAWe test against the evaluation set plus adversarial cases — malformed tool outputs, conflicting instructions, and attempts to trigger actions outside the agent's scope.
- 7ReleaseWe release with monitoring and trace dashboards in place, expanding the agent's action authority only after real-world review, not as a default.
Architecture & engineering considerations
- Tool & function-calling scopeEvery callable tool is an explicit, versioned function with a strict input/output schema. The agent has no general-purpose shell, API, or system access — if a tool doesn't exist for an action, the agent cannot take it.
- Permission tiers & approval gatesRead-only lookup tools and state-changing action tools sit in separate permission tiers. Anything classified as irreversible or high-risk requires an explicit human approval step before it runs.
- Orchestration & loop controlAgents operate within a bounded number of steps and a defined timeout budget, with explicit stop conditions, so an unresolved task ends in escalation rather than an indefinite retry loop.
- Trace-level evaluation & observabilityEvaluation covers the agent's decision path — which tools it chose, in what order, and why — not just whether the final output looked reasonable.
- Human review checkpointsConfidence thresholds and action-risk tiers determine when a decision routes to a person before execution, rather than every action running unattended by default.
- Failure & fallback behaviourDefined behaviour for a failed tool call, an unexpected tool response, or an ambiguous instruction — the default is to stop and escalate, not to guess and proceed.
Where this fits
Is this the right fit?
- A good fit when...You have a specific workflow with too many judgment calls for simple rule-based automation, and you want the agent's authority bounded to a defined, auditable set of actions.
- Not a good fit when...The goal is an agent with open-ended autonomy, unrestricted system access, or no human review on outcomes that matter — we don't build to that scope.
- Typical engagement shapeA scoped pilot around one workflow, starting with read-only or low-risk actions, with evaluation and approval gates in place before any action authority expands.
Related services
- AI DevelopmentProduction-oriented AI systems, assistants, RAG platforms and intelligent automation for Nordic businesses.
- Business Process AutomationRule-based workflow automation for approvals, document routing, and system integrations, engineered without AI where AI isn't the real problem.
- API Development & Systems IntegrationAPI design, partner integrations, and systems-integration engineering connecting ERP, MES, WMS, and third-party platforms into a reliable data flow.
Frequently asked questions
What exactly can the agent do, and what can it not do?
The agent can only call the specific tools we define for it — for example, looking up an order or drafting a note. Anything outside that list isn't a capability the agent has access to; there's no general-purpose action it can improvise.
How do you prevent it from taking an unauthorized or irreversible action?
We separate read-only tools from state-changing ones, and any action classified as high-risk or irreversible requires an explicit human approval step before it executes.
How do you audit what the agent decided and why?
Every tool call, its arguments, and the reasoning that led to it are logged, so a specific decision can be reconstructed and reviewed after the fact, not just the final output.
What happens if the agent gets stuck or a tool call fails?
Agents run within a bounded number of steps and a defined timeout. A failed tool call or an ambiguous situation triggers a stop-and-escalate path rather than an open-ended retry loop.
Is this different from a chatbot that can use plugins?
Yes. A chatbot with plugins typically has loosely-bounded, general-purpose tool access. What we build starts from the opposite direction — an explicit, minimal list of actions, with approval gates and audit logging around each one.
Further reading
- AI Agents vs. Chatbots: What's the Real DifferenceChatbots, LLM chat assistants, and AI agents explained with a clear technical line, a comparison table, and a decision framework for your use case.
- AI Knowledge Assistants for Internal Operations: A Practical GuideA practical guide to internal AI knowledge assistants: how RAG grounds answers in your documents, rollout strategy, governance, and fit criteria.
Considering a AI Agents project?
Tell us which workflow you want an agent to handle and which of its actions would need a human sign-off — we'll map the tool boundaries before writing any code.