Posted on
• Artificial Intelligence

Artificial Intelligence Business Automation on Linux

Author
  • User
    linuxbash
    Posts by this author
    Posts by this author

Artificial Intelligence Business Automation on Linux (with Bash)

If your team still copy-pastes data between systems, drafts repetitive emails by hand, or triages support tickets manually, you’re leaving money and time on the table. The good news: with Linux, Bash, and a lightweight local AI service, you can automate a surprising amount of this work—cheaply, privately, and reliably.

This post shows why Linux is an ideal base for AI automation and gives you 4 concrete steps to ship your first automation this week, complete with commands for apt, dnf, and zypper.

Why build AI automation on Linux?

  • Cost and control: Run open models locally to avoid per-token cloud bills and keep sensitive data on-prem.

  • Scriptability: Bash, cron, systemd, and pipes make it trivial to glue tools together.

  • Reliability: Systemd timers, logs, and containers make long-running jobs boringly dependable.

  • Composability: Use curl to talk to AI over HTTP; process and route results with jq, sed, and friends.

1) Provision a minimal AI-friendly toolchain

Install a few cross-distro basics used in the examples below.

  • Ubuntu/Debian (apt):

    • sudo apt update
    • sudo apt install -y curl jq git podman redis-server

  • Fedora/RHEL/CentOS (dnf):

    • sudo dnf install -y curl jq git podman redis

  • openSUSE (zypper):

    • sudo zypper install -y curl jq git podman redis

Optional: start Redis (use the service name that exists on your distro).

  • sudo systemctl enable --now redis

  • or sudo systemctl enable --now redis-server

Why these packages?

  • curl: talk to AI HTTP APIs from Bash.

  • jq: parse and transform JSON responses safely.

  • git: version your automation scripts and prompts.

  • podman: run AI services or helpers in containers with rootless security.

  • redis: fast in-memory queue/cache for workflows (optional).

2) Run a local LLM microservice (Ollama)

Ollama is a tiny server that runs open-source LLMs locally and exposes a simple HTTP API. It’s perfect for Bash-based automations.

  • Install Ollama:

    • curl -fsSL https://ollama.com/install.sh | sh

  • Enable the user service so it starts automatically:

    • systemctl --user enable --now ollama

  • Pull a model (example: Llama 3.1 8B):

    • ollama pull llama3.1:8b

  • Quick test:

    • curl -s http://localhost:11434/api/generate -d '{"model":"llama3.1:8b","prompt":"Say hello in one short sentence.","stream":false}' | jq -r .response

Prefer containers? You can run it rootless with Podman:

  • podman run -d --name ollama -p 11434:11434 -v ollama:/root/.ollama ollama/ollama

  • podman exec -it ollama ollama pull llama3.1:8b

Now you have a local AI endpoint at http://localhost:11434 that any Bash script can call.

3) Automate a real task: support ticket triage from Bash

Let’s turn unstructured text (a customer ticket) into structured, actionable data using only curl and jq. The same pattern can power invoice routing, lead qualification, QA labeling, and more.

  • One-off classification example (the “hello world” of automation):

    • export TEXT="Customer can't log in to the portal after password reset; error 403 shows."
    • curl -s http://localhost:11434/api/generate -H "Content-Type: application/json" -d "{\"model\":\"llama3.1:8b\",\"prompt\":\"You are a ticket triage assistant. Classify the following ticket into strict JSON with keys: priority(one of: low, medium, high), category(one of: login, billing, bug, question), summary(<=12 words). Only output JSON. Ticket: ${TEXT}\",\"stream\":false}" | jq -r '.response' | jq -r '.priority + "," + .category + "," + .summary'

    The final line prints CSV like:

    • high,login,403 after password reset prevents portal access

  • Batch from a file (one ticket per line):

    • while IFS= read -r T; do curl -s http://localhost:11434/api/generate -H "Content-Type: application/json" -d "{\"model\":\"llama3.1:8b\",\"prompt\":\"Classify in strict JSON with keys: priority, category, summary. Only JSON. Ticket: ${T}\",\"stream\":false}" | jq -r '.response' | jq -r '[.priority,.category,.summary] | @csv'; done < tickets.txt >> triaged.csv

Tips for reliability:

  • Always ask the model for “Only output JSON” and validate with jq. If parsing fails, retry or route to a human queue.

  • Keep prompts versioned in Git so model behavior changes can be tracked.

  • Use set -euo pipefail in scripts and log to syslog or a file.

4) Schedule and observe it with systemd timers (or cron)

  • Create a simple triage script (example name: ~/triage.sh):

    • printf '%s\n' '#!/usr/bin/env bash' 'set -euo pipefail' ': "${MODEL:=llama3.1:8b}"' 'INPUT="${1:-tickets.txt}"' 'OUT="${2:-triaged.csv}"' 'touch "$OUT"' 'while IFS= read -r T; do R=$(curl -s http://localhost:11434/api/generate -H "Content-Type: application/json" -d "{\"model\":\"'"$MODEL"'\",\"prompt\":\"Classify in strict JSON with keys: priority(one of: low, medium, high), category(one of: login, billing, bug, question), summary(<=12 words). Only JSON. Ticket: '"${T//\"/\\\"}"'\",\"stream\":false}"); echo "$R" | jq -er ".response" | jq -r "[.priority,.category,.summary] | @csv" >> "$OUT" || echo "manual,unknown,PARSE_FAIL: ${T}" >> "$OUT"; done < "$INPUT"' > ~/triage.sh && chmod +x ~/triage.sh

  • Add a user-level systemd service and timer:

    • mkdir -p ~/.config/systemd/user

    • printf '%s\n' '[Unit]' 'Description=Triage tickets with local LLM' '' '[Service]' 'Type=oneshot' 'WorkingDirectory=%h' 'ExecStart=%h/triage.sh %h/tickets.txt %h/triaged.csv' > ~/.config/systemd/user/triage.service

    • printf '%s\n' '[Unit]' 'Description=Run ticket triage every 5 minutes' '' '[Timer]' 'OnCalendar=*:0/5' 'Persistent=true' '' '[Install]' 'WantedBy=timers.target' > ~/.config/systemd/user/triage.timer

    • systemctl --user daemon-reload

    • systemctl --user enable --now triage.timer
    • systemctl --user list-timers | grep triage
    • journalctl --user -u triage.service -f

Prefer cron? Ensure cron is installed/enabled.

  • Ubuntu/Debian (apt): sudo apt install -y cron && sudo systemctl enable --now cron

  • Fedora/RHEL/CentOS (dnf): sudo dnf install -y cronie && sudo systemctl enable --now crond

  • openSUSE (zypper): sudo zypper install -y cron && sudo systemctl enable --now cron

Add a crontab entry:

  • crontab -e

  • */5 * * * * /home/youruser/triage.sh /home/youruser/tickets.txt /home/youruser/triaged.csv >> /home/youruser/triage.log 2>&1

Real-world patterns you can ship next

  • Lead qualification: Score and tag inbound form submissions, then write rows to a CRM import CSV.

  • Invoice routing: Classify vendor, due date, and total; move PDFs into per-department folders; flag anomalies for review.

  • Inbox assistant: Summarize unread threads and suggest replies; move messages to folders by category.

  • Knowledge base matcher: Suggest top 3 docs to attach to a support ticket and paste links into the ticketing system.

Each of these is the same loop: fetch → prompt → validate JSON with jq → write result → schedule → observe.

Conclusion and next step (CTA)

Pick one repetitive task your team does daily. In the next hour:

  • Install the basics (curl, jq, and Ollama).

  • Pull a model (ollama pull llama3.1:8b).

  • Prototype a one-liner curl + jq pipeline that returns structured JSON.

  • Wrap it in a tiny Bash script and schedule it with a user-level systemd timer.

When you’ve saved an hour this week, reinvest it to harden prompts, add retries, and version everything in Git. If you want a follow-up post with a full workflow (queues with Redis, retries, and metrics), let me know which use case you’re targeting.

Related posts